Feedback-ID: ia2694551:Fastmail
Date: Sat, 6 Apr 2024 18:13:19 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
	pgsql-hackers@lists.postgresql.org,
 Jaime Casanova <jcasanov@systemguards.com.ec>
Subject: Re: LogwrtResult contended spinlock
Message-ID: <202404061613.g24s435wqigh@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <43269689137ce4f80224b58a4e162fb891a6fc4e.camel@j-davis.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202404061613.g24s435wqigh%40alvherre.pgsql>
Precedence: bulk

On 2024-Apr-05, Jeff Davis wrote:

> Minor comments:

> * 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.

Uhh ... my understanding of pg_atomic_compare_exchange_u64 is that
*expected is set to the value that's stored in *ptr prior to the
exchange.  Its comment

 * Atomically compare the current value of ptr with *expected and store newval
 * iff ptr and *expected have the same value. The current value of *ptr will
 * always be stored in *expected.

is actually not very clear, because what does "current" mean in this
context?  Is the original "current" value, or is it the "current" value
after the exchange?  Anyway, looking at the spinlock-emulated code for
pg_atomic_compare_exchange_u32_impl in atomics.c,

	/* perform compare/exchange logic */
	ret = ptr->value == *expected;
	*expected = ptr->value;
	if (ret)
		ptr->value = newval;

it's clear that *expected receives the original value, not the new one.

Because of this behavior, not doing the Max() would return the obsolete
value rather than the one we just installed.  (It would only work
correctly without Max() when our cmpxchg operation "fails", that is,
somebody else incremented the value past the one we want to install.)


Another reason is that when I used pg_atomic_monotonic_advance_u64 with
the Write and Flush pointers and did not have the Max(), the assertion
failed pretty quickly :-)

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
Al principio era UNIX, y UNIX habló y dijo: "Hello world\n".
No dijo "Hello New Jersey\n", ni "Hello USA\n".