From: "Tatsuo Ishii" <is...@postgresql.org>
Last time I tested in following way, max_connections in pg_control of
standby did not reflect the change in primary.
1) stop primary
2) stop standby
3) change max_connections to 4 in primary
4) change max_connections to 4 in standby
5) start primary
6) start standby but it failed as I said before
So the particular WAL record was not sent to standby?
I'm going to test again...
That's because the parameter is checked at the beginning of recovery (i.e.
at standby start) before XLOG_PARAMETER_CHANGE is received and applied on
the standby. Please see CheckRequiredParameterValues() in StartupXLOG().
To persist the max_connections change:
1) stop primary
2) change max_connections on the primary
3) start primary
4) watch pg_stat_replication to wait until the standby is sync with the
primary (XLOG_PARAMETER_CHANGE is applied)
5) stop standby
6) change max_connections on the standby
7) start standby
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
