From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | craig(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender? |
Date: | 2016-11-22 03:35:21 |
Message-ID: | 20161122.123521.199973807.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
At Mon, 21 Nov 2016 21:39:07 -0500, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmoZh6M5bTmtZZm1vBpFGHmeNgESe4UrJ3-OwKnu56SKB7g(at)mail(dot)gmail(dot)com>
> On Mon, Nov 21, 2016 at 3:21 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> > I'm still interested in hearing comments from experienced folks about
> > whether it's sane to do this at all, rather than have similar
> > duplicate signal handling for the walsender.
>
> Well, I mean, if it's reasonable to share code in a given situation,
> that is generally better than NOT sharing code...
Walsender handles SIGUSR1 completely different way from normal
backends. The procsignal_sigusr1_handler is designed to work as
the peer of SendProcSignal (not ProcSendSignal:). Walsender is
just using a latch to be woken up. It has nothing to do with
SendProcSignal.
IMHO, I don't think walsender is allowed to just share the
backends' handler for a practical reason that pss_signalFlags can
harm.
If you need to expand the function of SIGUSR1 of walsender, more
thought would be needed.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2016-11-22 03:35:36 | Re: Parallel bitmap heap scan |
Previous Message | Tsunakawa, Takayuki | 2016-11-22 03:18:50 | Re: Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly |