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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: postgresql(at)thequod(dot)de
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array
Date: 2014-03-25 14:26:56
Message-ID: 13133.1395757616@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

postgresql(at)thequod(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2014-03-25 14:36:47 Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array
Previous Message Tom Lane 2014-03-25 14:21:15 Re: BUG #9722: select ILIKE is not case insensitive in UTF8 cyrillic