Re: LogwrtResult contended spinlock - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: LogwrtResult contended spinlock
Date
Msg-id 43269689137ce4f80224b58a4e162fb891a6fc4e.camel@j-davis.com
Whole thread Raw
In response to Re: LogwrtResult contended spinlock  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: LogwrtResult contended spinlock
Re: LogwrtResult contended spinlock
List pgsql-hackers
On Fri, 2024-04-05 at 13:54 +0200, Alvaro Herrera wrote:
> Couldn't push: I tested with --disable-atomics --disable-spinlocks
> and
> the tests fail because the semaphore for the atomic variables is not
> always initialized.  This is weird -- it's like a client process is
> running at a time when StartupXLOG has not initialized the variable
> ...
> so the initialization in the other place was not completely wrong.

It looks like you solved the problem and pushed the first patch. Looks
good to me.

Patch 0002 also looks good to me, after a mostly-trivial rebase (just
remember to initialize logCopyResult).

Minor comments:

* You could consider using a read barrier before reading the Copy ptr,
or using the pg_atomic_read_membarrier_u64() variant. I don't see a
correctness problem, but it might be slightly more clear and I don't
see a lot of downside.

* Also, I assume that the Max() call in
pg_atomic_monotonic_advance_u64() is just for clarity? Surely the
currval cannot be less than _target when it returns. I'd probably just
do Assert(currval >= _target) and then return currval.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Next
From: Jacob Champion
Date:
Subject: Re: Security lessons from liblzma