| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Florian Pflug <fgp(at)phlo(dot)org> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alvaro Herrera <alvherre(at)commandprompt(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:45:08 |
| Message-ID: | AANLkTikhQRxZnF8nQpx4N8C7bXgu2srbGnqT91SO12Bd@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> 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?
I don't think there's much point in getting excited about the order in
which things exit. If we're agreed (and we seem to be, modulo Tom)
that the backends should exit quickly if the postmaster dies, then
worrying about whether the utility processes exit slightly before or
slightly after that doesn't excite me very much.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-01-14 16:48:16 | Re: Error code for "terminating connection due to conflict with recovery" |
| Previous Message | Tom Lane | 2011-01-14 16:44:00 | Re: Add support for logging the current role |