Re: Executing pg_createsubscriber with a non-compatible control file
Michael Banck <mbanck@gmx.net>
From: Michael Banck <mbanck@gmx.net>
To: Michael Paquier <michael@paquier.xyz>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Euler Taveira <euler@eulerto.com>
Date: 2025-10-17T08:32:32Z
Lists: pgsql-hackers
Attachments
Hi, On Wed, Oct 08, 2025 at 09:22:48AM +0900, Michael Paquier wrote: > On Tue, Oct 07, 2025 at 11:51:45AM -0700, Masahiko Sawada wrote: > > Just to be clear, did you mean that pg_checksums and pg_rewind already > > do such checks? IIUC pg_checksums does CRC check for the control file, > > and if we execute v18-pg_checksums against v17-cluster we end up with > > a similar error but with a different log message like "pg_checksums: > > error: pg_control CRC value is incorrect". Those log messages are not > > helpful either. > > For the case of pg_checksums, we don't really have a constraint based > on the major version, currently. However, there is a PG_VERSION_NUM > hardcoded when syncing the data folder, so we are pretty much assuming > that it is the case already. > > A check based on PG_VERSION has more benefits in the long-term, IMO. > When the CRC check of the control file fails, it would be tempting to > use some of the contents read from the control file but that would > also mean that we could expose some corrupted values to the user, so > that would not be useful. So it seems the decision was that pg_checksums does not need this major version check? I agree that it is not entirely obvious is does, but on the other hand, those "pg_control CRC value is incorrect" are not helpful either. But even if pg_controldata() manages to read the control file, pg_checksums then errors out with "cluster is not compatible with this version of pg_checksums" (without further information) in case the control file version is different. I tried a few combinations, and current HEAD works with v18 clusters, while v16 pg_checksums can read v17 pg_control but then errors out due to that having a different version. All other combinations I tried so far yield the CRC error. So I think something like the attached should also be applied. A while ago I was actually looking at doing the exact same thing you did, i.e. extracting the PG_VERSION check out of pg_rewind for usage in pg_checksums but got side-tracked. While looking at the commit message of fa55be2a5, I noticed "This puts pg_createsubscriber in line with the documentation" and now I wonder whether the current major version dependency of pg_checksums shouldn't be mentioned in the documentation as well? If (that is a tall order maybe) on the other hand we agree that pg_checksums should work across major versions, then maybe the proper fix (on top of making sure everything else works correctly for each version) would be to teach get_controlfile() how to read older control files somehow, and pass it a major version as argument? Not sure that wouldn't be a hazard/ maintenance-nightmare and I don't volunteer to do that. Michael
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pg_checksums: Use new routine to retrieve data of PG_VERSION
- a7c30422004a 19 (unreleased) landed
-
pg_createsubscriber: Use new routine to retrieve data of PG_VERSION
- fa55be2a506a 19 (unreleased) landed
-
pg_resetwal: Use new routine to retrieve data of PG_VERSION
- c6a6cd53d3ab 19 (unreleased) landed
-
pg_combinebackup: Use new routine to retrieve data of PG_VERSION
- e4775e42cade 19 (unreleased) landed
-
pg_upgrade: Use new routine to retrieve data of PG_VERSION
- a7d8052910d6 19 (unreleased) landed
-
Introduce frontend API able to retrieve the contents of PG_VERSION
- cd0be131ba6f 19 (unreleased) landed