Re: Executing pg_createsubscriber with a non-compatible control file

On Fri, Oct 17, 2025 at 10:32:32AM +0200, Michael Banck wrote:
> 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.

I just did not feel strongly about adding the check, but now that we
have the version API we could also do it, based on the case of PGDATA
with a cluster that has a control version different than HEAD:
$ pg_checksums $PGDATA
pg_checksums: error: pg_control CRC value is incorrect

> So I think something like the attached should also be applied.

I see that you have used the same error message. That works for me.
Any comments and/or objections from others?

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

With the addition of the version check in the binary, there is no
downside in documenting this requirement.

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

I cannot get excited about the complications and the extra
maintenance. Attempting backward-compatibility for the sake of this
tool would bring its own set of bugs because we would need to maintain
the same control data structures across multiple branches, labelled
based on the control file versions. The current state of the tree is
simpler now.
--
Michael