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
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 |