Re: Standby server won't start

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

In response to

Responses

Browse pgsql-hackers by date

  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