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

  1. Consistency check should compare last record replayed, not last record read.

  2. Update minimum recovery point on truncation.