Message-ID: <43269689137ce4f80224b58a4e162fb891a6fc4e.camel@j-davis.com>
Subject: Re: LogwrtResult contended spinlock
From: Jeff Davis <pgsql@j-davis.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>, Bharath Rupireddy
	 <bharath.rupireddyforpostgres@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, 
 pgsql-hackers@lists.postgresql.org, Jaime Casanova
 <jcasanov@systemguards.com.ec>
Date: Fri, 05 Apr 2024 11:22:40 -0700
In-Reply-To: <202404051154.am63tvpedo5p@alvherre.pgsql>
References: <202404051154.am63tvpedo5p@alvherre.pgsql>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/43269689137ce4f80224b58a4e162fb891a6fc4e.camel%40j-davis.com>
Precedence: bulk

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.=C2=A0 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 >=3D _target) and then return currval.

Regards,
	Jeff Davis