Re: kill -KILL: What happens?
От | Robert Haas |
---|---|
Тема | Re: kill -KILL: What happens? |
Дата | |
Msg-id | AANLkTinL3zzQPm7wt3gxT5mZ4jajFDLf7kwiaJcLwJ1-@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: kill -KILL: What happens? (Florian Pflug <fgp@phlo.org>) |
Список | pgsql-hackers |
On Sat, Jan 15, 2011 at 6:27 AM, Florian Pflug <fgp@phlo.org> wrote: > On Jan14, 2011, at 17:45 , Robert Haas wrote: >> On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug <fgp@phlo.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. > > Tom seems to think that as our utility processes gain importance, one day > we might require one to outlive all the backends, and that whatever solution > we adopt should allow us to arrange for that. Or at least this how I > understood him. Well, there's certainly ONE of those already: the logging collector. But it already has its own solution to this problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: