Re: Consistently use the XLogRecPtrIsInvalid() macro
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, 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-19T19:17:37Z
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 →
-
Replace literal 0 with InvalidXLogRecPtr for XLogRecPtr assignments
- ec3174407164 19 (unreleased) landed
-
Replace pointer comparisons and assignments to literal zero with NULL
- ec782f56b0c3 19 (unreleased) landed
-
Use XLogRecPtrIsValid() in various places
- a2b02293bc65 19 (unreleased) landed
-
Introduce XLogRecPtrIsValid()
- d2965f627fe3 14.20 landed
- c0031d461324 18.1 landed
- 723cc84db50a 16.11 landed
- 49b45999f3b2 15.15 landed
- 33727aff18d0 17.7 landed
- 20bafb097288 13.23 landed
- 06edbed47862 19 (unreleased) landed
On Wed, Nov 19, 2025 at 12:47 PM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote: > > True, but if they write any new code, and care about it compiling with > > older minor releases, this is a potential pitfall. > > Why given that 06edbed4786 has been back patched through 13? I do not know how to make the phrase "older minor releases" any more clear. You and Álvaro seem to be under the impression that nobody will ever try to compile code written after this change from a point release that we shipped before this change. While I don't think that will be a common thing to do, I'm not sure where you get the idea that older minor releases completely cease to be relevant when we release a new one. That's just not how it works. I bet if we look in a few years we'll find modules on PGXN that have #ifdef logic in them to make sure they can work with both XLogRecPtrIsInvalid and XLogRecPtrIsValid. Probably most won't; a lot of extensions don't need either macro anyway. But what do you think that an extension maintainer is going to do if their build breaks at some point, on master or in the back-branches? Do you think they're just going to do a hard switch to the new macro? Because that's not what I will do if this breaks something I have to maintain. I'll certainly make it work both ways, somehow or other. And I bet everyone else will do the same. And that would be totally fine and reasonable if this were fixing an actual problem. -- Robert Haas EDB: http://www.enterprisedb.com