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 CABPTF7WNrbFd5+RDpw07cugweRAXuwGAtOwTp0yR8ug8dts8Tg@mail.gmail.com
Whole thread Raw
In response to Re: Add progressive backoff to XactLockTableWait functions  (Xuneng Zhou <xunengzhou@gmail.com>)
List pgsql-hackers
Hi,

> Some changes in v10:
>
> 1) XidWaitHashLock is used for all operations on XidWaitHash though
> might be unnecessary for some cases.
> 2) Field pg_atomic_uint32 waiter_count was removed from the
> XidWaitEntry. The start process now takes charge of cleaning up the
> XidWaitHash entry after waking up processes.
> 3) pg_atomic_uint32 xidWaiterNum is added to avoid unnecessary lock
> acquire & release and htab look-up while there's no xid waiting.
>
> Hope this could eliminate some subtleties.
>
> Exponential backoff in earlier patches is simple and effective for
> alleviating cpu overhead in extended waiting; however it could also
> bring unwanted latency for more sensitive use cases like logical
> walsender on cascading standbys. Unfortunately, I am unable to come up
> with a solution that is correct, effective and simple in all cases.
>

v11 removed this erroneous optimization:

3) pg_atomic_uint32 xidWaiterNum is added to avoid unnecessary lock
> acquire & release and htab look-up while there's no xid waiting.

Best,
Xuneng

Attachment

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Refactoring: Use soft error reporting for *_opt_error functions
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Conflict detection for update_deleted in logical replication