Executing pg_createsubscriber with a non-compatible control file
От | Michael Paquier |
---|---|
Тема | Executing pg_createsubscriber with a non-compatible control file |
Дата | |
Msg-id | aONDWig0bIGilixs@paquier.xyz обсуждение исходный текст |
Ответы |
Re: Executing pg_createsubscriber with a non-compatible control file
|
Список | pgsql-hackers |
Hi all, (Adding Euler in CC.) I have mentioned that on this thread: https://www.postgresql.org/message-id/aOM-T6iojyzb7OVB@paquier.xyz Attempting to execute pg_createsubscriber compiled with a version of PG_CONTROL_VERSION incompatible with the standby we want to switch to a logical replica leads to the following error: $ pg_createsubscriber -D $HOME/data/5433 \ -P "host=/tmp port=5432" -d postgres pg_createsubscriber: error: control file appears to be corrupt For example, setup a cluster based on v17 and run the command. This is confusing, because the control file is not corrupted, pg_createsubscriber is just missing the fact that the major version it is compiled with is not able to manipulate the control file of the target data folder. We enforce such checks for other tools, like pg_checksums or pg_rewind, and I don't see why pg_createsubscriber should be an exception? One simple thing that could be done is to grab the first line of the standby's PG_VERSION, at least, so as we have a check that does not depend on the contents of the control file, and it would unlikely be corrupted. Having a check based on PG_CONTROL_VERSION would be a few lines less, of course, that we could try in parallel of the CRC check report if the value is sane-ish, from a past version. Thoughts? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: