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 CABPTF7VsmuXUiXr00okzcd39Z-6udNp9wOXLj=2X2wZv3Afkcw@mail.gmail.com
Whole thread Raw
In response to Re: Add progressive backoff to XactLockTableWait functions  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Add progressive backoff to XactLockTableWait functions
List pgsql-hackers
Hi,

I spent some time digging deeper into the KnownAssignedXids logic in
procarray.c and made a few refinements. Below are some observations
and questions I’d like to discuss.

1)  Present usage (AFAICS)
It appears that logical decoding is the only place that waits for an
XID on a standby.  The single call-site is SnapBuildWaitSnapshot(),
which waits in a simple loop:

for (off = 0; off < running->xcnt; off++)
{
    TransactionId xid = running->xids[off];

    if (TransactionIdIsCurrentTransactionId(xid))
        elog(ERROR, "waiting for ourselves");

    if (TransactionIdFollows(xid, cutoff))
        continue;

    XactLockTableWait(xid, NULL, NULL, XLTW_None);
}

So each backend seems to block on one XID at a time.

2) Picking the waiter data structure
Given that behaviour, the total number of concurrent waits can’t exceed
MaxBackends.  If logical-slot creation stays the primary consumer for
now and for future, I’m wondering
whether a simple fixed-size array (or even a single global
ConditionVariable) might be sufficient.

In the patch I currently size the hash table the same as
KnownAssignedXids (TOTAL_MAX_CACHED_SUBXIDS), but that may well be
conservative.

3) Some trims
I’ve removed WakeAllXidWaiters() and call WakeXidWaiters() at each
point where an XID is deleted from KnownAssignedXids.

Feedback would be much appreciated.

Best,
Xuneng

Attachment

pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: Changing shared_buffers without restart
Next
From: Fabrice Chapuis
Date:
Subject: Re: failover logical replication slots