Re: Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?
Дата
Msg-id 20161122.123521.199973807.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?
Список pgsql-hackers
Hello,

At Mon, 21 Nov 2016 21:39:07 -0500, Robert Haas <robertmhaas@gmail.com> wrote in
<CA+TgmoZh6M5bTmtZZm1vBpFGHmeNgESe4UrJ3-OwKnu56SKB7g@mail.gmail.com>
> On Mon, Nov 21, 2016 at 3:21 AM, Craig Ringer <craig@2ndquadrant.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





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Parallel bitmap heap scan
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: WIP: multivariate statistics / proof of concept