Tom Lane wrote:
> > I've attached a patch that works for me. I hope I got it right.
>
> Applied with additional cleanup. You hadn't thought very carefully
> about additional state transitions that would have to be introduced
> into the postmaster state machine to support a new state --- for
> exa
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If you actually want the behavior you propose, then the only correct way
>> to implement it is to embed it into the state machine logic, ie, do the
>> CancelBackup inside PostmasterStateMachine in some state transition
>> taken after t
Tom Lane wrote:
> Why? That seems like an entirely arbitrary specification.
My resoning is that I think of smart/fast/immediate shutdown
as three different things.
For an immediate shutdown/crash thought it was best not to modify
anything to facilitate an analysis of the problem.
A fast shutdow
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> That should work, but isn't it better if backup_label is removed
> only if we know we're going to shutdown cleanly?
Why? That seems like an entirely arbitrary specification.
regards, tom lane
--
Sent via pgsql-patches mailing
Tom Lane wrote:
>>> Why not? It'll fall out of the state again immediately in
>>> PostmasterStateMachine, no, if we do a CancelBackup here?
>>
>> We cannot call CancelBackup there because that's exactly the state
>> in which a smart shutdown waits for a superuser to issue pg_stop_backup().
>
> Er
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why not? It'll fall out of the state again immediately in
>> PostmasterStateMachine, no, if we do a CancelBackup here?
> We cannot call CancelBackup there because that's exactly the state
> in which a smart shutdown waits for a super
Tom Lane wrote:
>>> Lastly, the changes to pmdie's SIGINT handling seem quite bogus.
>>> Don't you need to transition into WAIT_BACKUP rather than WAIT_BACKENDS
>>> state in that case too? Shouldn't you do CancelBackup *before*
>>> PostmasterStateMachine? The thing screams of race conditions.
>
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Lastly, the changes to pmdie's SIGINT handling seem quite bogus.
>> Don't you need to transition into WAIT_BACKUP rather than WAIT_BACKENDS
>> state in that case too? Shouldn't you do CancelBackup *before*
>> PostmasterStateMachine?
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Hmm. I've preivously been told not to use "Failed to" but instead
> > use "Could not"... Didn't notice that Tom used the other one in his
> > suggestion.
>
> > Tom (or someone else) - can you comment on if I misunderstood that
> > r
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Hmm. I've preivously been told not to use "Failed to" but instead use
> "Could not"... Didn't notice that Tom used the other one in his
> suggestion.
> Tom (or someone else) - can you comment on if I misunderstood that
> recommendation earlier, or if i
Albe Laurenz wrote:
> Tom Lane wrote:
> > I concur that the messages added to pg_ctl are bizarrely formatted.
> > Why would you put a newline in the middle of a sentence, when you
> > could equally well emit something like
> >
> > WARNING: online backup mode is active.
> > Shutdown will not comple
Tom Lane wrote:
> I concur that the messages added to pg_ctl are bizarrely formatted.
> Why would you put a newline in the middle of a sentence, when you
> could equally well emit something like
>
> WARNING: online backup mode is active.
> Shutdown will not complete until pg_stop_backup() is calle
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> I think the messages should not have a newline in the middle.
> Are you talking about the one in pg_ctl? We have other messages in
> pg_ctl that already do this, so I figured it was ok there...
I concur that the messages added
Alvaro Herrera wrote:
> I think the messages should not have a newline in the middle.
>
> Also, I am wondering if in PM_WAIT_BACKUP mode we should accept new
> connections from superusers only.
I spent some thought on that.
You'd need to wait until the user is authenticated before you can determi
Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
> > Applied with some minor changes to the error messages to make them
> > closer to our guidelines. (With my track record, it's not entirely
> > unlikely that someone will fix them further though :-P)
>
> I think the messages should not have a new
Magnus Hagander wrote:
> Applied with some minor changes to the error messages to make them
> closer to our guidelines. (With my track record, it's not entirely
> unlikely that someone will fix them further though :-P)
I think the messages should not have a newline in the middle.
Also, I am wond
Albe Laurenz wrote:
> Magnus Hagander wrote:
> > This doesn't look like our normal coding standards, and should
> > probably be changed:
> > + if (0 != stat(BACKUP_LABEL_FILE, &stat_buf))
> >
> > (there's a number of similar places)
>
> I see. Lacking guidelines, I now copied how stat(2) is use
Albe Laurenz wrote:
> Magnus Hagander wrote:
> > This doesn't look like our normal coding standards, and should
> > probably be changed:
> > + if (0 != stat(BACKUP_LABEL_FILE, &stat_buf))
> >
> > (there's a number of similar places)
>
> I see. Lacking guidelines, I now copied how stat(2) is use
18 matches
Mail list logo
