BUG #16215: Restore failes if number of workers in postgresql.conf is lower than on source system
The following bug has been logged on the website:
Bug reference: 16215
Logged by: Stefan Sonnenberg-Carstens
Email address: stefan.sonnenberg.carstens@gmail.com
PostgreSQL version: 10.11
Operating system: Linux
Description:
I tried to restore a binary backup (basebackup + WAL archives) onto a
smaller machine.
During restore the following log message was issued:
2020-01-17 07:14:20.524 UTC [19274] FATAL: hot standby is not possible
because max_worker_processes = 2 is a lower setting than on the master
server (its value was 8)
2020-01-17 07:14:20.526 UTC [19273] LOG: startup process (PID 19274) exited
with exit code 1
2020-01-17 07:14:20.526 UTC [19273] LOG: aborting startup due to startup
process failure
2020-01-17 07:14:20.541 UTC [19273] LOG: database system is shut down
pg_ctl: could not start server
Examine the log output.
The workaround was to raise the number of max_worker_process for the
recovery process to work and lowering it afterwords.
This seems to be a bug to me, as I don't see a technical connection between
these settings for the restore to be successful.
Cheers
Hello
No, this is intended and documented behavior: https://www.postgresql.org/docs/10/hot-standby.html#HOT-STANDBY-ADMIN
max_worker_processes must be at least the same as on primary. It is because exactly of our technical connection between recovery and the number of backends.
regards, Sergei
Hi Sergei,
as far as I understand these restrictions apply when hot_standby is set to
on AND a recovery.conf is missing.
I can confirm that hot_standby is commented out - is this setting on by
default?
grep hot_standby /etc/postgresql/10/main/postgresql.conf
#hot_standby = on # "off" disallows queries during
recovery
#hot_standby_feedback = off # send info from standby to prevent
Cheers
Am Fr., 17. Jan. 2020 um 08:58 Uhr schrieb Sergei Kornilov <sk@zsrv.org>:
Hello
No, this is intended and documented behavior:
https://www.postgresql.org/docs/10/hot-standby.html#HOT-STANDBY-ADMIN
max_worker_processes must be at least the same as on primary. It is
because exactly of our technical connection between recovery and the number
of backends.regards, Sergei
--
Stefan Sonnenberg-Carstens
IT Ingenieur
Hello
as far as I understand these restrictions apply when hot_standby is set to on AND a recovery.conf is missing.
When hot_standby is set to on AND a recovery.conf is PRESENT
Here is: https://github.com/postgres/postgres/blob/REL_10_STABLE/src/backend/access/transam/xlog.c#L6185
ArchiveRecoveryRequested is set if we found recovery.conf (see readRecoveryCommandFile)
I can confirm that hot_standby is commented out - is this setting on by default?
Yes, in postgresql 10 and newer.
regards, Sergei
Sure, during restore the recovery.conf is present (as I create it to be
able to do the restore).
After setting the parameter hot_standby explicitly to off, I can confirm
that it is no longer required to have higher values as on the source system.
Ok, It would be great to have this default as a comment in the
postgresql.conf that is created during cluster init as for many other
parameters.
Then, indeed, this is not a bug.
Thank you for this explanation and your help!
Cheers
Am Fr., 17. Jan. 2020 um 10:45 Uhr schrieb Sergei Kornilov <sk@zsrv.org>:
Hello
as far as I understand these restrictions apply when hot_standby is set
to on AND a recovery.conf is missing.
When hot_standby is set to on AND a recovery.conf is PRESENT
Here is:
https://github.com/postgres/postgres/blob/REL_10_STABLE/src/backend/access/transam/xlog.c#L6185
ArchiveRecoveryRequested is set if we found recovery.conf (see
readRecoveryCommandFile)I can confirm that hot_standby is commented out - is this setting on by
default?
Yes, in postgresql 10 and newer.
regards, Sergei
--
Stefan Sonnenberg-Carstens
IT Ingenieur