From: | "MauMau" <maumau307(at)gmail(dot)com> |
---|---|
To: | "Tatsuo Ishii" <ishii(at)postgresql(dot)org> |
Cc: | <rajeev(dot)rastogi(at)huawei(dot)com>, <ishii(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Standby server won't start |
Date: | 2014-03-21 13:04:19 |
Message-ID: | 5CCA9DDFB2574597A2A9053ED66F2F86@maumau |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: "Tatsuo Ishii" <ishii(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-03-21 13:24:08 | Re: [RFC] What should we do for reliable WAL archiving? |
Previous Message | Tatsuo Ishii | 2014-03-21 12:28:20 | Re: Standby server won't start |