Re: Consistently use the XLogRecPtrIsInvalid() macro

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