Hi,
On 2014-12-08 02:18:11 +0100, Petr Jelinek wrote:
> ...except for the removal of pause_at_recovery_target it seems, so I
> attached just that
Pushed.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
On 2014-12-08 02:18:11 +0100, Petr Jelinek wrote:
> On 08/12/14 02:06, Petr Jelinek wrote:
> >On 08/12/14 02:03, Michael Paquier wrote:
> >>On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek
> >>wrote:
> >>>Ok this patch does that, along with the rename to
> >>>recovery_target_action and
> >>>addition t
On Mon, Dec 8, 2014 at 10:18 AM, Petr Jelinek wrote:
> On 08/12/14 02:06, Petr Jelinek wrote:
>> Simon actually already committed something similar, so no need.
>>
>
> ...except for the removal of pause_at_recovery_target it seems, so I
> attached just that
Thanks! Removal of this parameter is get
On 08/12/14 02:06, Petr Jelinek wrote:
On 08/12/14 02:03, Michael Paquier wrote:
On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek
wrote:
Ok this patch does that, along with the rename to
recovery_target_action and
addition to the recovery.conf.sample.
This needs a rebase as at least da71632 and b
On 08/12/14 02:03, Michael Paquier wrote:
On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek wrote:
Ok this patch does that, along with the rename to recovery_target_action and
addition to the recovery.conf.sample.
This needs a rebase as at least da71632 and b8e33a8 are conflicting.
Simon actuall
On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek wrote:
> Ok this patch does that, along with the rename to recovery_target_action and
> addition to the recovery.conf.sample.
This needs a rebase as at least da71632 and b8e33a8 are conflicting.
--
Michael
--
Sent via pgsql-hackers mailing list (pgs
On 05/12/14 16:49, Robert Haas wrote:
On Thu, Dec 4, 2014 at 8:45 AM, Michael Paquier
wrote:
Here is patch which renames action_at_recovery_target to
recovery_target_action everywhere.
Thanks, Looks good to me.
A couple of things that would be good to document as well in
recovery-config.sgml:
On Sat, Dec 6, 2014 at 12:49 AM, Robert Haas wrote:
> On Thu, Dec 4, 2014 at 8:45 AM, Michael Paquier
> wrote:
> >> Here is patch which renames action_at_recovery_target to
> >> recovery_target_action everywhere.
> > Thanks, Looks good to me.
> >
> > A couple of things that would be good to docu
On Thu, Dec 4, 2014 at 8:45 AM, Michael Paquier
wrote:
>> Here is patch which renames action_at_recovery_target to
>> recovery_target_action everywhere.
> Thanks, Looks good to me.
>
> A couple of things that would be good to document as well in
> recovery-config.sgml:
> - the fact that pause_at_r
On Thu, Dec 4, 2014 at 10:45 PM, Michael Paquier
wrote:
>
>
> On Thu, Dec 4, 2014 at 10:13 PM, Petr Jelinek
> wrote:
> > On 02/12/14 18:59, Robert Haas wrote:
> >>
> >> On Fri, Nov 28, 2014 at 11:59 AM, Petr Jelinek
> >> wrote:
> >
> > I'm a bit late to the party, but wouldn't
> >
>
On Thu, Dec 4, 2014 at 10:13 PM, Petr Jelinek wrote:
> On 02/12/14 18:59, Robert Haas wrote:
>>
>> On Fri, Nov 28, 2014 at 11:59 AM, Petr Jelinek
>> wrote:
>
> I'm a bit late to the party, but wouldn't
>
> recovery_target_action = ...
>
> have been a better name for this?
On 4 December 2014 at 22:13, Petr Jelinek wrote:
> On 02/12/14 18:59, Robert Haas wrote:
>>
>> On Fri, Nov 28, 2014 at 11:59 AM, Petr Jelinek
>> wrote:
>
> I'm a bit late to the party, but wouldn't
>
> recovery_target_action = ...
>
> have been a better name for this? It'd
On 02/12/14 18:59, Robert Haas wrote:
On Fri, Nov 28, 2014 at 11:59 AM, Petr Jelinek wrote:
I'm a bit late to the party, but wouldn't
recovery_target_action = ...
have been a better name for this? It'd be in line with the other
recovery_target_* parameters, and also a bit shorter than the imh
On Fri, Nov 28, 2014 at 11:59 AM, Petr Jelinek wrote:
>>> I'm a bit late to the party, but wouldn't
>>>
>>> recovery_target_action = ...
>>>
>>> have been a better name for this? It'd be in line with the other
>>> recovery_target_* parameters, and also a bit shorter than the imho
>>> somewhat ugly
On 28/11/14 17:46, Alex Shulgin wrote:
Christoph Berg writes:
Re: Petr Jelinek 2014-11-25 <5474efea.2040...@2ndquadrant.com>
Patch committed.
Before I go and rebase that recovery.conf -> GUC patch on top of
this... is it final?
I think so, perhaps sans the name mentioned below.
Than
Christoph Berg writes:
> Re: Petr Jelinek 2014-11-25 <5474efea.2040...@2ndquadrant.com>
>> >Patch committed.
Before I go and rebase that recovery.conf -> GUC patch on top of
this... is it final?
>>
>> Thanks!
>
> I'm a bit late to the party, but wouldn't
>
> recovery_target_action = ...
>
>
On Wed, Nov 26, 2014 at 5:15 AM, Simon Riggs wrote:
> On 25 November 2014 at 14:06, Fujii Masao wrote:
>> On Thu, Nov 20, 2014 at 5:35 AM, Simon Riggs wrote:
>>> On 19 November 2014 16:41, Fujii Masao wrote:
On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas
wrote:
> On Wed, Nov 19,
On Wed, Nov 26, 2014 at 7:10 PM, Christoph Berg wrote:
> Re: Petr Jelinek 2014-11-25 <5474efea.2040...@2ndquadrant.com>
>> >Patch committed.
>>
>> Thanks!
>
> I'm a bit late to the party, but wouldn't
>
> recovery_target_action = ...
>
> have been a better name for this? It'd be in line with the o
Re: Petr Jelinek 2014-11-25 <5474efea.2040...@2ndquadrant.com>
> >Patch committed.
>
> Thanks!
I'm a bit late to the party, but wouldn't
recovery_target_action = ...
have been a better name for this? It'd be in line with the other
recovery_target_* parameters, and also a bit shorter than the im
On 25/11/14 21:15, Simon Riggs wrote:
On 25 November 2014 at 14:06, Fujii Masao wrote:
On Thu, Nov 20, 2014 at 5:35 AM, Simon Riggs wrote:
On 19 November 2014 16:41, Fujii Masao wrote:
On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote
On 25 November 2014 at 14:06, Fujii Masao wrote:
> On Thu, Nov 20, 2014 at 5:35 AM, Simon Riggs wrote:
>> On 19 November 2014 16:41, Fujii Masao wrote:
>>> On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
> If we ask for PAUSE an
On Thu, Nov 20, 2014 at 5:35 AM, Simon Riggs wrote:
> On 19 November 2014 16:41, Fujii Masao wrote:
>> On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
>>> On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
If we ask for PAUSE and we're not in HotStandby it just ignores it,
which
On 19 November 2014 22:47, Petr Jelinek wrote:
> On 19/11/14 19:51, Simon Riggs wrote:
>>
>> On 19 November 2014 16:11, Petr Jelinek wrote:
>>
We need to be able to tell the difference between a crashed Startup
process and this usage.
As long as we can tell, I don't mind how w
On 19/11/14 19:51, Simon Riggs wrote:
On 19 November 2014 16:11, Petr Jelinek wrote:
We need to be able to tell the difference between a crashed Startup
process and this usage.
As long as we can tell, I don't mind how we do it.
Suggestions please.
Different exit code?
Try this one.
O
On 19 November 2014 16:41, Fujii Masao wrote:
> On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
>> On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
>>> If we ask for PAUSE and we're not in HotStandby it just ignores it,
>>> which means it changes into PROMOTE. My feeling is that we shoul
On 19 November 2014 16:11, Petr Jelinek wrote:
>> We need to be able to tell the difference between a crashed Startup
>> process and this usage.
>>
>> As long as we can tell, I don't mind how we do it.
>>
>> Suggestions please.
>>
>
> Different exit code?
Try this one.
--
Simon Riggs
On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
> On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
>> If we ask for PAUSE and we're not in HotStandby it just ignores it,
>> which means it changes into PROMOTE. My feeling is that we should
>> change that into a SHUTDOWN, not a PROMOTE.
>
>
On 19/11/14 16:47, Simon Riggs wrote:
On 19 November 2014 13:13, Simon Riggs wrote:
Also, for the Shutdown itself, why are we not using
kill(PostmasterPid, SIGINT)?
Done
Other plan is to throw a FATAL message.
That gives a clean, fast shutdown rather than what looks like a crash.
I'
On 2014-11-19 16:04:49 +, Simon Riggs wrote:
> On 19 November 2014 15:57, Andres Freund wrote:
> > On 2014-11-19 15:47:05 +, Simon Riggs wrote:
> >> > Also, for the Shutdown itself, why are we not using
> >> >kill(PostmasterPid, SIGINT)?
> >>
> >> Done
> >
> > I don't think that's ok.
On 19/11/14 17:04, Simon Riggs wrote:
On 19 November 2014 15:57, Andres Freund wrote:
On 2014-11-19 15:47:05 +, Simon Riggs wrote:
Also, for the Shutdown itself, why are we not using
kill(PostmasterPid, SIGINT)?
Done
I don't think that's ok. The postmaster is the one that should be
On 19 November 2014 15:57, Andres Freund wrote:
> On 2014-11-19 15:47:05 +, Simon Riggs wrote:
>> > Also, for the Shutdown itself, why are we not using
>> >kill(PostmasterPid, SIGINT)?
>>
>> Done
>
> I don't think that's ok. The postmaster is the one that should be in
> control, not some s
On 2014-11-19 15:47:05 +, Simon Riggs wrote:
> > Also, for the Shutdown itself, why are we not using
> >kill(PostmasterPid, SIGINT)?
>
> Done
I don't think that's ok. The postmaster is the one that should be in
control, not some subprocess.
I fail to see the win in simplicity over using
On 19 November 2014 13:13, Simon Riggs wrote:
> I've reworded docs a little.
Done
> If we ask for PAUSE and we're not in HotStandby it just ignores it,
> which means it changes into PROMOTE. My feeling is that we should
> change that into a SHUTDOWN, not a PROMOTE.
Done
>
> Also, for the Shut
On 19/11/14 14:13, Simon Riggs wrote:
On 18 November 2014 22:05, Petr Jelinek wrote:
OK, promote works for me as well, I attached patch that changes continue to
promote so you don't have to find and replace everything yourself. The
changed doc wording probably needs to be checked.
I've rewor
On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
> If we ask for PAUSE and we're not in HotStandby it just ignores it,
> which means it changes into PROMOTE. My feeling is that we should
> change that into a SHUTDOWN, not a PROMOTE.
To me, that seems like a definite improvement.
--
Robert Ha
On 18 November 2014 22:05, Petr Jelinek wrote:
> OK, promote works for me as well, I attached patch that changes continue to
> promote so you don't have to find and replace everything yourself. The
> changed doc wording probably needs to be checked.
I've reworded docs a little.
Which led me to
On 18/11/14 12:57, Simon Riggs wrote:
On 31 October 2014 15:18, Petr Jelinek wrote:
Attached is the v2 of the patch with the review comments addressed (see
below).
...
Done, there is now action_at_recovery_target which can be set to either
pause, continue or shutdown, defaulting to pause (wh
On 31 October 2014 15:18, Petr Jelinek wrote:
> Attached is the v2 of the patch with the review comments addressed (see
> below).
...
> Done, there is now action_at_recovery_target which can be set to either
> pause, continue or shutdown, defaulting to pause (which is same as old
> behavior of pa
Hi,
Attached is the v2 of the patch with the review comments addressed (see
below).
On 29/10/14 21:08, Petr Jelinek wrote:
On 29/10/14 20:27, Asif Naeem wrote:
1. It seems that following log message need to be more descriptive about
reason for shutdown i.e.
+ if (recov
On 29/10/14 20:27, Asif Naeem wrote:
I have spent sometime to review the patch, overall patch looks good, it
applies fine and make check run without issue. If recovery target is
specified and shutdown_at_recovery_target is set to true, it shutdown
the server at specified recovery point. I do have
Hi Petr,
I have spent sometime to review the patch, overall patch looks good, it
applies fine and make check run without issue. If recovery target is
specified and shutdown_at_recovery_target is set to true, it shutdown the
server at specified recovery point. I do have few points to share i.e.
1.
On 11 September 2014 16:02, Petr Jelinek wrote:
>> What about adding something like action_at_recovery_target=pause|shutdown
>> instead of increasing the number of parameters?
>>
>
> That will also increase number of parameters as we can't remove the current
> pause one if we want to be backwards
On 10/09/14 13:13, Fujii Masao wrote:
On Wed, Sep 10, 2014 at 1:45 AM, Petr Jelinek wrote:
Hi,
I recently wanted several times to have slave server prepared at certain
point in time to reduce the time it takes for it to replay remaining WALs
(say I have pg_basebackup -x on busy db for example)
On Wed, Sep 10, 2014 at 1:45 AM, Petr Jelinek wrote:
> Hi,
>
> I recently wanted several times to have slave server prepared at certain
> point in time to reduce the time it takes for it to replay remaining WALs
> (say I have pg_basebackup -x on busy db for example).
In your example, you're think
Hi,
I recently wanted several times to have slave server prepared at certain
point in time to reduce the time it takes for it to replay remaining
WALs (say I have pg_basebackup -x on busy db for example).
Currently the way to do it is to have pause_at_recovery_target true
(default) and wait un
45 matches
Mail list logo
