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