Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)
MauMau <maumau307@gmail.com>
From: "MauMau" <maumau307@gmail.com>
To: "Alvaro Herrera" <alvherre@2ndquadrant.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "Andres Freund" <andres@2ndquadrant.com>,
"Peter Eisentraut" <peter_e@gmx.net>, <pgsql-hackers@postgreSQL.org>
Date: 2013-06-21T13:57:13Z
Lists: pgsql-hackers
From: "Alvaro Herrera" <alvherre@2ndquadrant.com>
> Actually, I think it would be cleaner to have a new state in pmState,
> namely PM_IMMED_SHUTDOWN which is entered when we send SIGQUIT. When
> we're in this state, postmaster is only waiting for the timeout to
> expire; and when it does, it sends SIGKILL and exits. Pretty much the
> same you have, except that instead of checking AbortStartTime we check
> the pmState variable.
Are you suggesting simplifying the following part in ServerLoop()? I
welcome the idea if this condition becomes simpler. However, I cannot
imagine how.
if (AbortStartTime > 0 && /* SIGKILL only once */
(Shutdown == ImmediateShutdown || (FatalError && !SendStop)) &&
now - AbortStartTime >= 10)
{
SignalAllChildren(SIGKILL);
AbortStartTime = 0;
}
I thought of adding some new state of pmState for some reason (that might be
the same as your idea).
But I refrained from doing that, because pmState has already many states. I
was afraid adding a new pmState value for this bug fix would complicate the
state management (e.g. state transition in PostmasterStateMachine()). In
addition, I felt PM_WAIT_BACKENDS was appropriate because postmaster is
actually waiting for backends to terminate after sending SIGQUIT. The state
name is natural.
I don't have strong objection to your idea if it makes the code cleaner and
more understandable. Thank you very much.
Regards
MauMau
Commits
-
Consistency check should compare last record replayed, not last record read.
- 970fb12de121 9.3.0 cited
-
Update minimum recovery point on truncation.
- 7bffc9b7bf9e 9.3.0 cited