From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Marco Pfatschbacher <Marco_Pfatschbacher(at)genua(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PATCH: Keep one postmaster monitoring pipe per process |
Date: | 2016-09-16 18:23:39 |
Message-ID: | 20160916182339.2qe2bj3zgk6zfkgk@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-09-16 18:24:33 | Re: Rename max_parallel_degree? |
Previous Message | Robert Haas | 2016-09-16 18:10:16 | design for a partitioning feature (was: inheritance) |