Use standard SIGHUP and SIGTERM handlers in autoprewarm module

Поиск
Список
Период
Сортировка
От Bharath Rupireddy
Тема Use standard SIGHUP and SIGTERM handlers in autoprewarm module
Дата
Msg-id CALj2ACXPorUqePswDtOeM_s82v9RW32E1fYmOPZ5NuE+TWKj_A@mail.gmail.com
обсуждение исходный текст
Ответы Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers
Hi,

Autoprewarm module is using it's own SIGHUP(apw_sigterm_handler, got_sigterm) and SIGTERM(apw_sighup_handler, got_sighup) handlers which are similar to standard signal handlers(except for a difference [1]). Isn't it good to remove them and  use standard SignalHandlerForConfigReload and SignalHandlerForShutdownRequest?

Attaching the patch for the above changes.

Looks like the commit[2] replaced custom handlers with standard handlers.

Thoughts?

[1] apw_sigterm_handler() and apw_sighup_handler() use MyProc->procLatch
if (MyProc)
        SetLatch(&MyProc->procLatch);
where as standard handlers use MyLatch
    SetLatch(MyLatch);
Both MyProc->procLatch and MyLatch point to same, see comment from global.c
/*
 * MyLatch points to the latch that should be used for signal handling by the
 * current process. It will either point to a process local latch if the
 * current process does not have a PGPROC entry in that moment, or to
 * PGPROC->procLatch if it has. Thus it can always be used in signal handlers,
 * without checking for its existence.

 */
struct Latch *MyLatch;

(gdb) p MyProc->procLatch
$6 = {is_set = 0, is_shared = true, owner_pid = 1448807}
(gdb) p MyLatch
$7 = (struct Latch *) 0x7fcacc6d902c
(gdb) p &MyProc->procLatch
$8 = (Latch *) 0x7fcacc6d902c
(gdb) p *MyLatch
$9 = {is_set = 0, is_shared = true, owner_pid = 1448807}

[2] commit 1e53fe0e70f610c34f4c9e770d108cd94151342c
Author: Robert Haas <rhaas@postgresql.org>
Date:   2019-12-17 13:03:57 -0500

    Use PostgresSigHupHandler in more places.

    There seems to be no reason for every background process to have
    its own flag indicating that a config-file reload is needed.
    Instead, let's just use ConfigFilePending for that purpose
    everywhere.

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
Вложения

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Support for OUT parameters in procedures
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Parallel INSERT (INTO ... SELECT ...)