Re: PATCH: Keep one postmaster monitoring pipe per process
От | Andres Freund |
---|---|
Тема | Re: PATCH: Keep one postmaster monitoring pipe per process |
Дата | |
Msg-id | 20160916182339.2qe2bj3zgk6zfkgk@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: PATCH: Keep one postmaster monitoring pipe per process (Marco Pfatschbacher <Marco_Pfatschbacher@genua.de>) |
Ответы |
Re: PATCH: Keep one postmaster monitoring pipe per process
Re: PATCH: Keep one postmaster monitoring pipe per process |
Список | pgsql-hackers |
Hi, On 2016-09-16 09:55:48 +0200, Marco Pfatschbacher wrote: > On Thu, Sep 15, 2016 at 12:26:16PM -0700, Andres Freund wrote: > > Yikes, that's a pretty absurd implementation. > > Not when you take into account that it's been written over 20 years ago ;) Well, that doesn't mean it can't be fixed ;) > > I'm not quite sure I understand why this an issue here - there shouldn't > > ever be events on this fd, so why is the kernel waking up all processes? > > It'd kinda makes sense it'd wake up all processes if there's one > > waiting, but ... ? > > Every read is an event, and that's what PostmasterIsAlive does. But in most places we only do a PostmasterIsAlive if WaitLatch returns WL_POSTMASTER_DEATH. The only walreceiver related place that doesn't is WalRcvWaitForStartPosition(). If that's indeed the cause of your issues this quite possibly could be fixed by doing the if (!PostmasterIsAlive()) exit(1); check not unconditionally, but only after the WaitLatch at the end of the loop, and only if WL_POSTMASTER_DEATH is returned by WaitLatch()? That'll be a minor behaviour change for the WALRCV_RESTARTING, but that seems fine, we'll just loop once more outside (after a quick glance at least). Andres
В списке pgsql-hackers по дате отправления: