Re: Standby server won't start - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Standby server won't start
Date
Msg-id 20140322.093332.290509071732757701.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Standby server won't start  ("MauMau" <maumau307@gmail.com>)
Responses Re: Standby server won't start  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
> 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

Unfotunately this did not work for me. pg_stat_replication showed
replay_location and sent_location are identical, and I assume the
standby is sync with the primary in step #4. Still the standby did not
start in #7 with same error message I showed. This is PostgreSQL
9.3.3. Also pg_controldata <standby DB cluster> showed the old
max_connections at #7. So I guess XLOG_PARAMETER_CHANGE has not been
sent for some reason. Will look into this.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe Reply-To:
Next
From: Thom Brown
Date:
Subject: Partial index locks