| 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 | 
| 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 |