From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Daniel Hahler <postgresql(at)thequod(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array |
Date: | 2014-03-25 15:26:06 |
Message-ID: | 20140325152606.GG9567@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Daniel Hahler wrote:
> On 25.03.2014 15:36, Alvaro Herrera wrote:
> > 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.
>
> Yes, the container was frozen during reboot:
>
> From the host:
> Mar 25 11:54:48 HN kernel: [ 76.237452] CT: 144: started
> Mar 25 11:55:03 HN kernel: [ 91.201145] CT: 144: restored
>
> OpenVZ uses "suspend" by default to stop containers on host reboots.
> I will change this to "stop" for the PostgreSQL container, but still this seems like something PostgreSQL should handle better.
Of course. We will accept your patch as soon as you discover the bug.
Thanks for the offer.
> FWIW, I have just suspended and started the container manually, and
> PostgreSQL kept running (upgraded to 9.3.4 in the meantime).
>
> Maybe it's a bug with OpenVZ and how it restores some resources after rebooting the host?
Maybe it forgot to restore the shared memory state.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Hahler | 2014-03-25 15:39:20 | Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array |
Previous Message | Daniel Hahler | 2014-03-25 15:17:52 | Re: BUG #9721: Fatal error on startup: no free slots in PMChildFlags array |