Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array

Tom Lane wrote:
> postgresql@thequod.de writes:
> > PostgreSQL just failed to startup after a reboot (which was forced via
> > remote Ctrl-Alt-Delete on the PostgreSQL's containers host):
>
> > 2014-03-24 13:32:47 CET LOG:  could not receive data from client: Connection
> > reset by peer
> >     2014-03-25 12:32:17 CET FATAL:  no free slots in PMChildFlags array
> > 2014-03-25 12:32:17 CET LOG:  process 9975 releasing ProcSignal slot 108,
> > but it contains 0
> > 2014-03-25 12:32:17 CET LOG:  process 9974 releasing ProcSignal slot 109,
> > but it contains 0
> > 2014-03-25 12:32:17 CET LOG:  process 9976 releasing ProcSignal slot 110,
> > but it contains 0
>
> That's odd (and as you say, unexpected) but this log extract doesn't give
> much clue as to how we got into this state.  What was going on before
> this?  In particular, it's hard to call this "failure to start up" when
> you evidently had a hundred or so postmaster child processes already.
> Could there have been some unexpected surge in the number of connection
> attempts just after the database came up?  Also, this extract doesn't look
> like anything that would've caused the postmaster to decide to shut down
> again, so what happened after that?  Or in short, I want to see the rest
> of the log not just this part.

Here's my guess --- this is a virtualized system that somehow dumped
some state to disk to hibernate while the host was being rebooted; and
then, when the host was up again, it tried to resurrect the virtual
machine and found things to be all inconsistent.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services