Re: Consistently use the XLogRecPtrIsInvalid() macro
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Quan Zongliang <quanzongliang@yeah.net>,
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2025-10-28T11:40:24Z
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 28/10/2025 10:53, Quan Zongliang wrote: > On 10/28/25 4:13 PM, Bertrand Drouvot wrote: >> While working on refactoring some code in [1], one of the changes was: >> >> - if (initial_restart_lsn != InvalidXLogRecPtr && >> - initial_restart_lsn < oldestLSN) >> + XLogRecPtr restart_lsn = s->data.restart_lsn; >> + >> + if (restart_lsn != InvalidXLogRecPtr && >> + restart_lsn < oldestLSN) >> >> Sawada-san suggested to use the XLogRecPtrIsInvalid() macro here. >> >> But this != InvalidXLogRecPtr check was existing code, so why not >> consistently use XLogRecPtrIsInvalid() where we check equality >> against InvalidXLogRecPtr? >> >> At the time the current XLogRecPtrIsInvalid() has been introduced >> (0ab9d1c4b316) all the InvalidXLogRecPtr equality checks were done >> using XLogRecPtrIsInvalid(). >> >> But since, it has changed: I looked at it and this is not the case >> anymore in 20 files. >> >> PFA, patches to $SUBJECT. To ease the review, I created one patch >> per modified file. >> >> I suspect the same approach could be applied to some other macros >> too. Let's start with XLogRecPtrIsInvalid() first. > > Agree. This patch has made the code style more consistent. And using > such macros is also in line with the usual practice. Just like > OidIsValid and TransactionIdIsValid. Back in the day, XLogRecPtrIsInvalid() was needed because XLogRecPtr was a struct. 'x == InvalidXLogRecPtr' simply did not work. I don't see much need for it nowadays. In fact I wonder if we should go in the other direction and replace XLogRecPtrIsInvalid(x) calls with 'x == InvalidXLogRecPtr'. It's also a bit cumbersome that we have XLogRecPtrIsInvalid() rather than XLogRecPtrIsValid(). That's inconsistent with OidIsValid and TransactionIdInValid, and it leads to an awkward double negative 'if (!XLogRecPtrIsInvalid(x))' if you want to check that 'x' is valid. Overall I'm inclined to do nothing. But if anything, perhaps introduce XLogRecPtrIsValid(x) and switch to that, or replace XLogRecPtrIsInvalid(x) calls with 'x == InvalidXLogRecPtr' - Heikki