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
