Re: Add progressive backoff to XactLockTableWait functions - Mailing list pgsql-hackers

From Xuneng Zhou
Subject Re: Add progressive backoff to XactLockTableWait functions
Date
Msg-id CABPTF7WDqGczxLhWrESoj6WqdR374iEQV_dBP9dDG2xHxBCz6Q@mail.gmail.com
Whole thread Raw
In response to Re: Add progressive backoff to XactLockTableWait functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi, Tom!

Thanks for looking at this.

On Fri, Aug 8, 2025 at 2:20 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Xuneng Zhou <xunengzhou@gmail.com> writes:
> > V9 replaces the original partitioned xid-wait htab with a single,
> > unified one, reflecting the modest entry count and rare contention for
> > waiting. To prevent possible races when multiple backends wait on the
> > same XID for the first time in XidWaitOnStandby, a dedicated lock has
> > been added to protect the hash table.
>
> This seems like adding quite a lot of extremely subtle code in
> order to solve a very small problem.  I thought the v1 patch
> was about the right amount of complexity.

Yeah, this patch is indeed complex, and the complexity might not be
well-justified—given the current use cases, it feels like we’re paying
a lot for very little. TBH, getting the balance right between
efficiency gains and cost, in terms of both code complexity and
runtime overhead, is beyond my current ability here, since I’m
touching many parts of the code for the first time. Every time I
thought I’d figured it out, new subtleties surfaced—though I’ve
learned a lot from the exploration and hacking. We may agree on the
necessity of fixing this issue, but not yet on how to fix it. I’m open
to discussion and suggestions.

Best,
Xuneng



pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: Improve tab completion for various SET/RESET forms
Next
From: Ashutosh Bapat
Date:
Subject: Re: Allow REPLICA IDENTITY with CREATE TABLE statement