Re: Consistently use the XLogRecPtrIsInvalid() macro

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Quan Zongliang <quanzongliang(at)yeah(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Consistently use the XLogRecPtrIsInvalid() macro
Date: 2025-11-19 16:14:53
Message-ID: CA+TgmoZi28-mfUeaKOs6GvT69EDDngUSC521rcwGfhBXeqv3nw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 6, 2025 at 2:48 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> Okay, thanks, I have applied that one to all stable branches, except I
> didn't add the judgemental comment about XLogRecPtrIsInvalid().

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. Over
the alternative actually chosen, I would have preferred (a) not doing
this project at all or (b) making a hard switch in master to use the
new macro everywhere and remove the old one, while leaving the
back-branches unchanged or (c) dropping the use of the macro
altogether, in that order of preference.

That sad, I'm not arguing for a revert. My basic position is that this
wasn't worth the switching cost, not that it was intrinsically a bad
idea.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2025-11-19 16:20:27 Re: POC: make mxidoff 64 bits
Previous Message Nathan Bossart 2025-11-19 16:08:37 Re: Trigger more frequent autovacuums of heavy insert tables