Re: stopgap fix for signal handling during restore_command
| От | Nathan Bossart |
|---|---|
| Тема | Re: stopgap fix for signal handling during restore_command |
| Дата | |
| Msg-id | 20231011032934.GA847236@nathanxps13 обсуждение исходный текст |
| Ответ на | Re: stopgap fix for signal handling during restore_command (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: stopgap fix for signal handling during restore_command
|
| Список | pgsql-hackers |
On Tue, Oct 10, 2023 at 09:54:18PM -0500, Nathan Bossart wrote: > On Tue, Oct 10, 2023 at 04:40:28PM -0700, Andres Freund wrote: >> I'd make these elog(PANIC), I think. The paths are not performance critical >> enough that a single branch hurts, so the overhead of the check is irrelevant, >> and the consequences of calling ProcKill() twice for the same process are very >> severe. > > Right. Should we write_stderr_signal_safe() and then abort() to keep these > paths async-signal-safe? Hm. I see that elog() is called elsewhere in proc_exit(), and it does not appear to be async-signal-safe. Am I missing something? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: