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 по дате отправления: