Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array
Date
Msg-id 13133.1395757616@sss.pgh.pa.us
Whole thread Raw
In response to BUG #9721: Fatal error on startup: no free slots in PMChildFlags array  (postgresql@thequod.de)
Responses Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-bugs
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.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #9722: select ILIKE is not case insensitive in UTF8 cyrillic
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array