Re: Issue with the PRNG used by Postgres - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Issue with the PRNG used by Postgres
Date
Msg-id 20240411200347.mx7hqwsbmkmhthng@awork3.anarazel.de
Whole thread Raw
In response to Re: Issue with the PRNG used by Postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2024-04-10 21:52:59 -0400, Tom Lane wrote:
> Less drastically, I wonder if we should call finish_spin_delay
> at all in these off-label uses of perform_spin_delay.  What
> we're trying to measure there is the behavior of TAS() spin loops,
> and I'm not sure that what LWLockWaitListLock and the bufmgr
> callers are doing should be assumed to have timing behavior
> identical to that.

I think the difference between individual spinlocks is bigger than between
spinlocks and lwlock/buffer header locks.


I think we probably should move away from having any spinlocks.  I tried to
just replace them with lwlocks, but today the overhead is too big. The issue
isn't primarily the error handling or such, but the fact that rwlocks are more
expensive than simple exclusive locks. The main differences are:

1) On x86 a spinlock release just needs a compiler barrier, but an rwlock
   needs an atomic op.

2) Simple mutex acquisition is easily done with an atomic-exchange, which is
   much harder for an rwlock (as the lock has more states, so just setting to
   "locked" and checking the return value isn't sufficient). Once a lock is
   contended, a atomic compare-exchange ends up with lots of retries due to
   concurrent changes.

It might be that we can still get away with just removing spinlocks - to my
knowledge we have one very heavily contended performance critical spinlock,
XLogCtl->Insert->insertpos_lck.  I think Thomas and I have come up with a way
to do away with that spinlock.


OTOH, there are plenty other lwlocks where we pay the price of lwlocks being
an rwlock, but just use the exclusive mode. So perhaps we should just add a
exclusive-only lwlock variant.


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Issue with the PRNG used by Postgres
Next
From: Tom Lane
Date:
Subject: Re: Issue with the PRNG used by Postgres