Re: kill -KILL: What happens?

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

In response to

Responses

Browse pgsql-hackers by date

  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