From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "David Fetter" <david(at)fetter(dot)org>, "PG Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: kill -KILL: What happens? |
Date: | 2011-01-14 16:28:54 |
Message-ID: | 0BC05187-20E6-4846-9052-1E343FEB5BE2@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan14, 2011, at 17:22 , Kevin Grittner wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
>
>> If postmaster dies, and then another backend crashes, then your
>> backend running "your honking big query" could run across
>> corrupted state and then you'd be in serious trouble.
>
> Worst of all, it could give bogus results without error. I really
> don't see a production use case for letting backends continue after
> postmaster failure -- unless you only kinda, sorta care whether
> committed data is actually retrievable or reported data is actually
> accurate.
I gather that the behaviour we want is for normal backends to exit
once the postmaster is gone, and for utility processes (bgwriter, ...)
to exit once all the backends are gone.
The test program I posted in this thread proves that FIFOs and select()
can be used to implement this, if we're ready to check for EOF on the
socket in CHECK_FOR_INTERRUPTS() every few seconds. Is this a viable
route to take?
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-01-14 16:36:38 | Re: Add support for logging the current role |
Previous Message | Stefan Kaltenbrunner | 2011-01-14 16:23:39 | Maintenance downtime for commitfest.postgresql.org and media.postgresql.org |