Re: Executing pg_createsubscriber with a non-compatible control file - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Executing pg_createsubscriber with a non-compatible control file
Date
Msg-id aOiirvWJzwdVCXph@paquier.xyz
Whole thread Raw
In response to Re: Executing pg_createsubscriber with a non-compatible control file  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Thu, Oct 09, 2025 at 11:22:47AM -0700, Masahiko Sawada wrote:
> +1, sounds like a good idea to improve user experience. I think we can
> use the API in pg_combinebackup.c too since it has a similar function,
> read_pg_version_file().

Please find attached what I am finishing with.  At the end, I have
designed an API that can be reused across the board for the following
tools that do the same things in the tree, removing some duplicated
code:
- pg_resetwal
- pg_upgrade
- pg_combinebackup

The routine that retrieves the contents gets a uint32 number, and it
is optionally possible to get the contents of PG_VERSION (pg_upgrade
wants that for tablespace paths, but that's really for pg_resetwal to
be able to show back buggy data):
extern uint32 get_pg_version(const char *datadir, char **version_str);

This support both the pre-v10 and the post-v10 version formats, for
pg_upgrade.

To ease comparisons with PG_MAJORVERSION_NUM, I have added a small
helper macro (see GET_PG_MAJORVERSION_NUM).

I have also applied the same method to pg_createsubscriber, on top of
that, to take care of my original issue.  I have not looked at other
places where the same concept could be applied, at least it's a start.

Thoughts or comments?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Sadhuprasad Patro
Date:
Subject: Improved TAP tests by replacing sub-optimal uses of ok() with better Test::More functions
Next
From: Michael Paquier
Date:
Subject: Incorrect version number given to sync_pgdata() in pg_combinebackup.c