On 2015-08-11 13:53:15 +0900, Tatsuo Ishii wrote:
> Today I encountered an interesting situation.
>
> 1) A streaming replication primary server and a standby server is
> running. At this point max_connections = 100 on both servers.
>
> 2) Shutdown both servers.
>
> 3) Change max_connections to 1100 on both servers and restart both
> servers.
>
> 4) The primary server happily started but the standby server won't
> because of lacking resource.
>
> 5) Shutdown both servers.
>
> 6) Restore max_connections to 100 on both servers and restart both
> servers.
>
> 7) The primary server happily started but the standby server won't
> because of the reason below.
>
> 32695 2015-08-11 13:46:22 JST FATAL: hot standby is not possible because max_connections = 100 is a lower setting
thanon the master server (its value was 1100)
> 32695 2015-08-11 13:46:22 JST CONTEXT: xlog redo parameter change: max_connections=1100 max_worker_processes=8
max_prepared_xacts=10max_locks_per_xact=64 wal_level=hot_standby wal_log_hints=off
> 32693 2015-08-11 13:46:22 JST LOG: startup process (PID 32695) exited with exit code 1
> 32693 2015-08-11 13:46:22 JST LOG: terminating any other active server processes
>
> I think this is because pg_control on the standby remembers that the
> previous primary server's max_connections = 1100 even if the standby
> server fails to start. Shouldn't we update pg_control file only when
> standby succeeds to start?
I don't think that'd help. There's a WAL record generated that contains
the master's settings (C.f. XLogReportParameters()) and when replaying
we check that the local settings are compatible with the master's. So
you'll either have to have higher settings on the standby for at least
one restart or, maybe easier given 4), simply start the standby for a
second with hot_standby = off, and then re-enable it after it has
replayed pending WAL.
Greetings,
Andres Freund