Re: Async-unsafe functions in signal handlers
От
Denis Smirnov
Тема
Re: Async-unsafe functions in signal handlers
Дата
Msg-id
EBEA13C1-5900-49CB-8DED-5AFE23167C27@arenadata.io
Ответ на
Re: Async-unsafe functions in signal handlers (Denis Smirnov)
Список
Дерево обсуждения
Async-unsafe functions in signal handlers Denis Smirnov <sd@arenadata.io>
Re: Async-unsafe functions in signal handlers Andrey Borodin <x4mmm@yandex-team.ru>
Re: Async-unsafe functions in signal handlers Denis Smirnov <sd@arenadata.io>
Re: Async-unsafe functions in signal handlers Robert Haas <robertmhaas@gmail.com>
Re: Async-unsafe functions in signal handlers Tom Lane <tgl@sss.pgh.pa.us>
Re: Async-unsafe functions in signal handlers Denis Smirnov <sd@arenadata.io>
Re: Async-unsafe functions in signal handlers Andres Freund <andres@anarazel.de>
Re: Async-unsafe functions in signal handlers Denis Smirnov <sd@arenadata.io>
Re: Async-unsafe functions in signal handlers Denis Smirnov <sd@arenadata.io>
Honestly, I don’t know what to do with bgworker_die(). At the moment it produces ereport(FATAL) with async-unsafe proc_exit_prepare() and exit() underhood. I can see three solutions:
1. Leave the code as is. Then SIGTERM can produce deadlocks in bgworker's signal handler. The locked process can terminated with an immediate shutdown of the cluster. May be it is ok as we don’t expect to send SIGTERM to bgworker too often.
2. Use async-safe _exit() in a signal handler instead of proc_exit_prepare() and exit(). In this case we’ll have to go through cluster recovery as the bgworker doesn't properly clean its shared memory. This solution is even worth than immediate shutdown as we recover for every SIGTERM have been sent to bgworker.
3. Set a signal flag inside the handler (something like miscadmin.h XXX_INTERRUPTS() macros). So it becomes an extension developer's responsibility to properly handle this flag in the bgworker’s code. This approach breaks backward compatibility.
Best regards,
Denis Smirnov | Developer
sd@arenadata.io
Arenadata | Godovikova 9-17, Moscow 129085 Russia
Denis Smirnov | Developer
sd@arenadata.io
Arenadata | Godovikova 9-17, Moscow 129085 Russia
В списке pgsql-hackers по дате отправления
От: Robert Haas
Дата: