Thread: 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
recoveryand the number of backends.
 

regards, Sergei

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