Re: Consistently use the XLogRecPtrIsInvalid() macro

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: 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-03 07:47:28
Message-ID: aQheEEBgcchKUDvw@ip-10-97-1-34.eu-west-3.compute.internal
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Fri, Oct 31, 2025 at 01:19:50PM +0100, Álvaro Herrera wrote:
> On 2025-Oct-31, Bertrand Drouvot wrote:
>
> > After giving it more thought, I'm inclined to postpone the compiler warning
> > until XLogRecPtrIsValid() has been available for some time. The question is for
> > how long?
>
> Maybe we can mark it so that it becomes obsolete in a future version,
>
> #if PG_VERSION_NUM >= 210000
> [[obsolete]]
> #endif
> XLogRecPtrIsInvalid( .. )
>
> so that people using it today won't get any noise, but once they do get
> the warning, the versions without the other macro are already out of
> support, so they can switch to the new one easily. (This presupposes
> that we'd add the new macro to older branches as well, which shouldn't
> be a problem.) Only extensions wishing to support PG versions older
> than we support would have to work slightly harder, but that should be OK.

Yeah, I did not think of checking PG_VERSION_NUM for a "future" version, that's
a good idea! I did it that way in the attached (in 0002) and introduced
PG_DEPRECATED() (as suggested by Peter upthread).

The version check is done on 24 to ensure that the new macro is available on all
the supported major versions.

The PG_DEPRECATED() name and location (c.h) look fine to me but maybe there is
better suggestions.

I think the way it is done in the attached makes sense, it:

- introduces PG_DEPRECATED()
- provides a use case on how to use it (i.e using a version that is currently
in the future)
- ensures that XLogRecPtrIsInvalid() deprecation is "enforced" as of version 24
- ensures that not using XLogRecPtrIsInvalid() is documented (so that it should
not be used anymore, at least in core, even waiting for version 24)

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v4-0001-Introduce-XLogRecPtrIsValid-and-replace-XLogRecPt.patch text/x-diff 49.3 KB
v4-0002-Introduce-PG_DEPRECATED-and-deprecate-XLogRecPtrI.patch text/x-diff 2.6 KB
v4-0003-Replace-InvalidXLogRecPtr-comparisons-with-XLogRe.patch text/x-diff 39.2 KB
v4-0004-Replace-literal-0-comparisons-on-XLogRecPtr-with-.patch text/x-diff 1.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Kukushkin 2025-11-03 07:51:46 Re: Issue with logical replication slot during switchover
Previous Message Mats Kindahl 2025-11-03 07:27:12 Use stack-allocated StringInfoData