Re: [HACKERS] pg_ctl promote wait

2016-09-23 Thread Peter Eisentraut
On 9/22/16 11:16 AM, Masahiko Sawada wrote: > Commit e7010ce seems to forget to change help message of pg_ctl. > Attached patch. Fixed, thanks. I also added the -t option and reformatted a bit. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: [HACKERS] pg_ctl promote wait

2016-09-22 Thread Michael Paquier
On Fri, Sep 23, 2016 at 12:16 AM, Masahiko Sawada wrote: > On Thu, Sep 22, 2016 at 1:25 AM, Peter Eisentraut > wrote: >> On 8/11/16 9:28 AM, Michael Paquier wrote: >> Committed with that adjustment. Thanks... > Commit e7010ce seems to

Re: [HACKERS] pg_ctl promote wait

2016-09-22 Thread Masahiko Sawada
On Thu, Sep 22, 2016 at 1:25 AM, Peter Eisentraut wrote: > On 8/11/16 9:28 AM, Michael Paquier wrote: >> I have looked at them and the changes are looking fine for me. So I >> have switched the patch as ready for committer, aka you. >> >> Just a nit: >> +

Re: [HACKERS] pg_ctl promote wait

2016-09-21 Thread Peter Eisentraut
On 8/11/16 9:28 AM, Michael Paquier wrote: > I have looked at them and the changes are looking fine for me. So I > have switched the patch as ready for committer, aka you. > > Just a nit: > + if (wait_seconds > 0) > + { > + sleep(1); > + wait_seconds--; > +

Re: [HACKERS] pg_ctl promote wait

2016-08-11 Thread Michael Paquier
On Thu, Aug 11, 2016 at 3:24 AM, Peter Eisentraut wrote: > On 8/7/16 9:44 PM, Michael Paquier wrote: This is not a good >> idea, and the idea of putting a wait argument in get_controlfile does >> not seem a good interface to me. I'd rather see

Re: [HACKERS] pg_ctl promote wait

2016-08-10 Thread Peter Eisentraut
On 8/7/16 9:44 PM, Michael Paquier wrote: >>> This is not a good >>> >> idea, and the idea of putting a wait argument in get_controlfile does >>> >> not seem a good interface to me. I'd rather see get_controlfile be >>> >> extended with a flag saying no_error_on_failure and keep the wait >>> >>

Re: [HACKERS] pg_ctl promote wait

2016-08-07 Thread Michael Paquier
On Sat, Aug 6, 2016 at 10:43 AM, Peter Eisentraut wrote: > On 8/5/16 12:14 AM, Michael Paquier wrote: >> In do_stop, this patches makes the wait happen for a maximum of >> wait_seconds * 2, once when getting the control file information, and >> once when waiting

Re: [HACKERS] pg_ctl promote wait

2016-08-05 Thread Peter Eisentraut
On 8/5/16 12:14 AM, Michael Paquier wrote: > In do_stop, this patches makes the wait happen for a maximum of > wait_seconds * 2, once when getting the control file information, and > once when waiting for the server to shut down. That's not how I read it. get_controlfile() will decrease the

Re: [HACKERS] pg_ctl promote wait

2016-08-04 Thread Michael Paquier
On Wed, Aug 3, 2016 at 9:35 PM, Peter Eisentraut wrote: > Updated patch set for pg_ctl promote -w, incorporating AFAICT all of the > previous reviews, in particular Michael Paquier's changes to the > StartupXLOG() ordering, and rebasing on top of >

Re: [HACKERS] pg_ctl promote wait

2016-08-03 Thread Peter Eisentraut
Updated patch set for pg_ctl promote -w, incorporating AFAICT all of the previous reviews, in particular Michael Paquier's changes to the StartupXLOG() ordering, and rebasing on top of src/common/controldata_utils.c. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] pg_ctl promote wait

2016-04-07 Thread Peter Eisentraut
On 04/07/2016 01:22 AM, Michael Paquier wrote: On Wed, Mar 23, 2016 at 1:47 AM, David Steele wrote: On 3/16/16 12:19 PM, David Steele wrote: Hi Peter, On 3/9/16 3:08 PM, Michael Paquier wrote: Here are some comments about 0002 <...> I think that we had better do

Re: [HACKERS] pg_ctl promote wait

2016-04-06 Thread Michael Paquier
On Wed, Mar 23, 2016 at 1:47 AM, David Steele wrote: > On 3/16/16 12:19 PM, David Steele wrote: >> Hi Peter, >> >> On 3/9/16 3:08 PM, Michael Paquier wrote: >> >>> Here are some comments about 0002 >> <...> >>> I think that we had better do something like the attached first.

Re: [HACKERS] pg_ctl promote wait

2016-03-22 Thread David Steele
On 3/16/16 12:19 PM, David Steele wrote: > Hi Peter, > > On 3/9/16 3:08 PM, Michael Paquier wrote: > >> Here are some comments about 0002 > <...> >> I think that we had better do something like the attached first. >> Thoughts? > > It's been a week since Michael reviewed this patch. Could you

Re: [HACKERS] pg_ctl promote wait

2016-03-19 Thread David Steele
Hi Peter, On 3/9/16 3:08 PM, Michael Paquier wrote: > Here are some comments about 0002 <...> > I think that we had better do something like the attached first. > Thoughts? It's been a week since Michael reviewed this patch. Could you please comment on his proposed changes as soon as possible?

Re: [HACKERS] pg_ctl promote wait

2016-03-09 Thread Michael Paquier
On Mon, Feb 29, 2016 at 4:29 PM, Michael Paquier wrote: > On Mon, Feb 29, 2016 at 4:28 PM, Michael Paquier > wrote: >> I would suggest using >> $node_standby->poll_query_until('SELECT pg_is_in_recovery()') to >> validate the end of the test.

Re: [HACKERS] pg_ctl promote wait

2016-02-28 Thread Michael Paquier
On Mon, Feb 29, 2016 at 4:28 PM, Michael Paquier wrote: > I would suggest using > $node_standby->poll_query_until('SELECT pg_is_in_recovery()') to > validate the end of the test. Meh. SELECT NOT pg_is_in_recovery(). This will wait until the query returns true. --

Re: [HACKERS] pg_ctl promote wait

2016-02-28 Thread Michael Paquier
On Mon, Feb 29, 2016 at 10:30 AM, Peter Eisentraut wrote: > On 2/19/16 3:09 PM, Tom Lane wrote: >> 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

Re: [HACKERS] pg_ctl promote wait

2016-02-28 Thread Peter Eisentraut
On 2/19/16 3:09 PM, Tom Lane wrote: > 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. Here is a patch set around that idea. The subsequent discussion

Re: [HACKERS] pg_ctl promote wait

2016-02-19 Thread Tom Lane
Andres Freund writes: > On 2016-02-19 15:09:58 -0500, Tom Lane wrote: >> 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

Re: [HACKERS] pg_ctl promote wait

2016-02-19 Thread Andres Freund
On 2016-02-19 15:09:58 -0500, Tom Lane wrote: > Peter Eisentraut 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

Re: [HACKERS] pg_ctl promote wait

2016-02-19 Thread Tom Lane
Peter Eisentraut 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

Re: [HACKERS] pg_ctl promote wait

2016-02-19 Thread Tom Lane
Peter Eisentraut writes: > Is it safe to read pg_control externally without a lock? pg_controldata > will just report a CRC error and proceed, and if you're not sure you can > just run it again. But if a promotion fails every so often because of > concurrent pg_control writes,

Re: [HACKERS] pg_ctl promote wait

2016-02-19 Thread Andres Freund
On 2016-02-20 00:06:09 +0900, 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

Re: [HACKERS] pg_ctl promote wait

2016-02-19 Thread Andres Freund
On 2016-02-19 13:48:52 -0500, Peter Eisentraut wrote: > Is it safe to read pg_control externally without a lock? pg_controldata > will just report a CRC error and proceed, and if you're not sure you can > just run it again. But if a promotion fails every so often because of > concurrent

Re: [HACKERS] pg_ctl promote wait

2016-02-19 Thread Peter Eisentraut
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

Re: [HACKERS] pg_ctl promote wait

2016-02-19 Thread Peter Eisentraut
On 2/18/16 3:33 AM, Andres Freund wrote: > Hi, > > On 2016-02-17 21:47:50 -0500, Peter Eisentraut wrote: >> It would be nice if pg_ctl promote supported the -w (wait) option. >> >> How could pg_ctl determine when the promotion has finished? > > How about looking into pg_control?

Re: [HACKERS] pg_ctl promote wait

2016-02-19 Thread Fujii Masao
On Thu, Feb 18, 2016 at 5:45 PM, Simon Riggs wrote: > On 18 February 2016 at 08:33, Andres Freund wrote: >> >> Hi, >> >> On 2016-02-17 21:47:50 -0500, Peter Eisentraut wrote: >> > It would be nice if pg_ctl promote supported the -w (wait) option. +1

Re: [HACKERS] pg_ctl promote wait

2016-02-18 Thread Simon Riggs
On 18 February 2016 at 08:33, Andres Freund wrote: > Hi, > > On 2016-02-17 21:47:50 -0500, Peter Eisentraut wrote: > > It would be nice if pg_ctl promote supported the -w (wait) option. > > > > How could pg_ctl determine when the promotion has finished? > > How about looking

Re: [HACKERS] pg_ctl promote wait

2016-02-18 Thread Andres Freund
Hi, On 2016-02-17 21:47:50 -0500, Peter Eisentraut wrote: > It would be nice if pg_ctl promote supported the -w (wait) option. > > How could pg_ctl determine when the promotion has finished? How about looking into pg_control? ControlFileData->state ought to have the correct information.

Re: [HACKERS] pg_ctl promote wait

2016-02-18 Thread Simon Riggs
On 18 February 2016 at 02:47, Peter Eisentraut wrote: > It would be nice if pg_ctl promote supported the -w (wait) option. > > How could pg_ctl determine when the promotion has finished? > > We could query pg_is_in_recovery(), but that would require database > access, which we

[HACKERS] pg_ctl promote wait

2016-02-17 Thread Peter Eisentraut
It would be nice if pg_ctl promote supported the -w (wait) option. How could pg_ctl determine when the promotion has finished? We could query pg_is_in_recovery(), but that would require database access, which we got rid of in pg_ctl. We could check when recovery.conf is gone or recovery.done

[HACKERS] Pg_ctl promote -- wait for slave to be promoted fully ?

2012-08-07 Thread Magnus Hagander
Should we consider if we can make pg_ctl -w work for promote as well? The main problem is, I guess, that it can't log in - so wed' need something like PQping() that actually checked if it was master or slave? //Magnus -- Forwarded message -- From: Manoj Govindassamy

Re: [HACKERS] Pg_ctl promote -- wait for slave to be promoted fully ?

2012-08-07 Thread Fujii Masao
On Tue, Aug 7, 2012 at 10:22 PM, Magnus Hagander mag...@hagander.net wrote: Should we consider if we can make pg_ctl -w work for promote as well? +1 The main problem is, I guess, that it can't log in - so wed' need something like PQping() that actually checked if it was master or slave?

Re: [HACKERS] Pg_ctl promote -- wait for slave to be promoted fully ?

2012-08-07 Thread Robert Haas
On Tue, Aug 7, 2012 at 1:09 PM, Fujii Masao masao.fu...@gmail.com wrote: On Tue, Aug 7, 2012 at 10:22 PM, Magnus Hagander mag...@hagander.net wrote: Should we consider if we can make pg_ctl -w work for promote as well? +1 The main problem is, I guess, that it can't log in - so wed' need