Re: Proposal for Signal Detection Refactoring

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Proposal for Signal Detection Refactoring
Дата
Msg-id CAMsr+YF0dk=tRFVQ-a4BXnM-7dryX=DdpS013MNvSpP=jMTpOA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal for Signal Detection Refactoring  (Chris Travers <chris.travers@adjust.com>)
Список pgsql-hackers
On Wed, 6 Mar 2019 at 17:38, Chris Travers <chris.travers@adjust.com> wrote:

Here's a new patch.  No rush on it.  I am moving it to next commitfest anyway because as code documentation I think this is a low priority late in the release cycle.

While you're looking at signal detection changes I suggest making sure you get them right for the contribs that use explicit signal handling, like src/test/modules/worker_spi/ .

I'm actually pretty sure worker_spi is incorrect as it stands in the current codebase. It defines its own worker_spi_sighup and worker_spi_sigterm handlers. worker_spi_sigterm() sets a static bool got_sighup that's scoped to worker_spi.c . Importantly it does NOT set ipc.c's InterruptPending or ProcDiePending so the CHECK_FOR_INTERRUPTS() macro will not notice when a backend running worker_spi gets a SIGTERM. So long as worker_spi's own main loop is serviced regularly that's fine, but it means worker_spi won't react to signals at all if it's busy in a query or somewhere else in postgres code.

It's also worth paying attention to the walsender, which has its own signal handling, and pretty much anywhere else that has a pqsignal(...) call that isn't SIG_IGN, die, quickdie, startup_die or procsignal_sigusr1_handler:

    git grep -P 'pqsignal\(SIG(INT|HUP|TERM|QUIT|USR1|USR2), (?!die|startup_die|quickdie|procsignal_sigusr1_handler|SIG_IGN)' src/backend/


--
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise

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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: POC: converting Lists into arrays
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: SegFault on 9.6.14