Re: pg_ctl promote wait

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_ctl promote wait
Date: 2016-02-19 20:24:37
Message-ID: 20160219202437.tf7bcheicvitvqsd@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-02-19 15:09:58 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On 2/19/16 10:06 AM, Fujii Masao wrote:
> >> One concern is that there can be a "time" after the pg_control's state
> >> is changed to DB_IN_PRODUCTION and before the server is able to
> >> start accepting normal (not read-only) connections. So if users try to
> >> start write transaction just after pg_ctl promote -w ends, they might
> >> get an error because the server is still in recovery, i.e., the startup
> >> process is running.
>
> > I think that window would be acceptable.
>
> > If not, then the way to deal with it would seem to be to create an
> > entirely new mechanism to communicate with pg_ctl (e.g., a file) and
> > call that at the very end of StartupXLOG(). I'm not sure that that is
> > worth it.
>
> I see no need for an additional mechanism. Just watch pg_control until
> you see DB_IN_PRODUCTION state there, then switch over to the same
> connection probing that "pg_ctl start -w" uses.

That's afaics not sufficient if the standby was using hot standby, as
that'll let -w succeed immediately, no?

Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-02-19 20:33:25 Re: pg_ctl promote wait
Previous Message Andres Freund 2016-02-19 20:20:01 Re: checkpointer continuous flushing - V18