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
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 forget to change help message of pg_ctl.
> Attached patch.
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:
>> + if (wait_seconds > 0)
>> + {
>
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--;
> +
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 get_controlfile be
>> extended wit
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
>>> >> log
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 for the server to shut down.
>
> Th
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
wait_
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
> src/common/controldata_utils.c.
Glad to see a ne
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 Developm
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 something like the attache
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.
>>> Thoughts?
>>
>> It
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 pl
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?
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.
>
> Meh. SELECT NOT pg_is_in_recovery(). This will wait
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.
--
Michael
--
Sent via pgsql-hac
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 start -w" uses.
>
> He
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 ment
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 afaics not sufficient
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 accepting normal (not rea
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 to
>> start write t
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, that would make th
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 p
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 pg_contro
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 pro
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? ControlFileData->
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
>> > How could pg_ctl determine when the prom
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 into pg_control? Cont
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.
Regards
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 got rid of in pg_ct
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 app
On Tue, Aug 7, 2012 at 1:09 PM, Fujii Masao wrote:
> On Tue, Aug 7, 2012 at 10:22 PM, Magnus Hagander 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
On Tue, Aug 7, 2012 at 10:22 PM, Magnus Hagander 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?
Yes.
Regards
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
Date:
34 matches
Mail list logo
