Re: Resetting recovery target parameters in pg_createsubscriber
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Ilyasov Ian <ianilyasov@outlook.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "dlaaren8@gmail.com" <dlaaren8@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-06T03:58:07Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pg_createsubscriber: Improve handling of automated recovery configuration
- 639352d904c8 19 (unreleased) landed
On Sun, Oct 05, 2025 at 10:30:53PM +0000, Ilyasov Ian wrote: > Do we need info about recovery.conf here since patch applies only to > master? And actually, I think that you are pointing at a bug here. pg_createsubscriber does updates of the control file but it includes zero checks based on PG_CONTROL_VERSION to make sure that it is able to work with a version compatible with what's on disk. The CRC check would be reported as incorrect after calling get_controlfile(), but it's disturbing to claim that the control file looks corrupted. So, oops? [.. checks ..] The last control file update has been done in 44fe30fdab67, and attempting to run pg_createsubscriber on a v17 cluster leads to: $ pg_createsubscriber -D $HOME/data/5433 -P "host=/tmp port=5432" -d postgres pg_createsubscriber: error: control file appears to be corrupt So, yes, oops. We document that pg_cretesubscriber should have the same major version as the source and target servers, which is good. This error is no good, especially as checking it is just a few lines of code, and that the take is actually PG_CONTROL_VERSION for control file consistency. -- Michael