Feedback-ID: ie3de48e3:Fastmail
Date: Thu, 6 Nov 2025 20:48:11 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>,
	Michael Paquier <michael@paquier.xyz>, Heikki Linnakangas <hlinnaka@iki.fi>,
	Quan Zongliang <quanzongliang@yeah.net>, pgsql-hackers@lists.postgresql.org
Subject: Re: Consistently use the XLogRecPtrIsInvalid() macro
Message-ID: <202511061936.ivzq6rvsny27@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <aQywOKctVLwjDuuT@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: 
 <https://www.postgresql.org/message-id/202511061936.ivzq6rvsny27%40alvherre.pgsql>
Precedence: bulk

On 2025-Nov-06, Bertrand Drouvot wrote:

> I see, I would have introduced XLogRecPtrIsInvalid() on the back branches only
> if there is a need to (a bugfix that would make use of it). But yeah, I agree
> that would add extra "unnecessary" work, so done as you suggested in the
> attached. I checked that 0001 apply on the [14-18]_STABLE branches successfully.

Okay, thanks, I have applied that one to all stable branches, except I
didn't add the judgemental comment about XLogRecPtrIsInvalid().

I also pushed 0002+0004+0005 together as one commit, so now we have
XLogRecPtrIsValid() everywhere.

I did a couple of minor transformations, where the new code would end
doing "!XLogRecPtrIsValid(x) ? A : B" it seems clearer to remove the
negation and invert the other two arguments in the ternary.  We also had
this assertion,

-   Assert(XLogRecPtrIsInvalid(state->istartpoint) == (state->istarttli == 0));

which was being transformed to have a negation.  I chose to negate the
other side of the equality instead, that is,

+   Assert(XLogRecPtrIsValid(state->istartpoint) == (state->istarttli != 0));

which also seems clearer.

Now only 0003 remains ... I would change the complaining version to 21
there, because why not?

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)