Horton

Re: Consistently use the XLogRecPtrIsInvalid() macro

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, 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-19T17:27:30Z
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()

On Wed, Nov 19, 2025 at 11:49 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> > I'm rather late to the party here, but for what it's worth, I don't
> > really think this was a good idea. Anyone who wants to write
> > out-of-core code that works in the back-branches must still write it
> > the old way, or it will potentially fail on older minor releases.
>
> No, they don't need to.  Thus far, they can still keep their code the
> way it is.

True, but if they write any new code, and care about it compiling with
older minor releases, this is a potential pitfall.

>  The next patch in the series (not yet committed, but I
> intend to get it out at some point, unless there are objections) is
> going to add an obsolescence warning when their code is compiled with
> Postgres 21 -- by which time the minors without the new macro are going
> to be two years old.  Nobody needs to compile their code with minor
> releases that old.  So they can fix their code to work with Postgres 21
> and with all contemporary minors.  They don't need to ensure that their
> code compiles with minors older than that.

Well, if nobody needs to do this, then there's no problem, of course.
I doubt that's true, though.

> We could make that Postgres 22, but I don't think that makes any
> practical difference.
>
> Maybe you misunderstood what the patch is doing.

It's possible, but fundamentally I think it's about replacing
XLogRecPtrIsInvalid with XLogRecPtrIsValid, and what I'm saying is I
wouldn't have chosen to do that. I agree that it would have been
better to do it that way originally, but I disagree with paying the
switching cost, especially in the back-branches.

-- 
Robert Haas
EDB: http://www.enterprisedb.com