Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array
От | Tom Lane |
---|---|
Тема | Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array |
Дата | |
Msg-id | 13133.1395757616@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #9721: Fatal error on startup: no free slots in PMChildFlags array (postgresql@thequod.de) |
Ответы |
Re: BUG #9721: Fatal error on startup: no free slots in
PMChildFlags array
|
Список | 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 по дате отправления: