Re: Consistently use the XLogRecPtrIsInvalid() macro

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
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
Date: 2025-11-06T14:27:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Replace literal 0 with InvalidXLogRecPtr for XLogRecPtr assignments

  2. Replace pointer comparisons and assignments to literal zero with NULL

  3. Use XLogRecPtrIsValid() in various places

  4. Introduce XLogRecPtrIsValid()

Attachments

Hi,

On Thu, Nov 06, 2025 at 10:06:13AM +0100, Álvaro Herrera wrote:
> On 2025-Nov-06, Bertrand Drouvot wrote:
> 
> > Subject: [PATCH v5 1/4] Introduce XLogRecPtrIsValid() and replace
> >  XLogRecPtrIsInvalid() calls
> 
> > XLogRecPtrIsInvalid() is inconsistent with the affirmative form of other
> > *IsValid() macros and leads to awkward double negative.
> > 
> > This commit introduces XLogRecPtrIsValid() and replace all the
> > XLogRecPtrIsInvalid() calls.
> > 
> > It also adds a comment mentioning that new code should use XLogRecPtrIsValid()
> > instead of XLogRecPtrIsInvalid() and that XLogRecPtrIsInvalid() could be
> > deprecated in the future.
> 
> I think we should do this in two steps.  First, introduce
> XLogRecPtrIsValid(), don't use it anywhere, backpatch this one.  This
> would alleviate potential backpatching pains when using the new macro in
> future bugfixes. 

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.

> The uppercase name looks a bit ugly.  We use lowercase for other uses of
> __attribute__, e.g. pg_attribute_aligned().  Also, probably add
> "attribute" to the name, for consistency with those.

Right, replaced by pg_attribute_deprecated() in the attached.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com