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
example,
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 the last
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 list
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
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 called.
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 complete until
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
recommendation
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? The thing
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 it still
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.
I suspect
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 superuser to
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 used in
other
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 used in
other
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
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 newline in
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 determine
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 to
17 matches
Mail list logo