Re: stopgap fix for signal handling during restore_command

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: stopgap fix for signal handling during restore_command
Дата
Msg-id 20230224043323.GA821522@nathanxps13
обсуждение исходный текст
Ответ на Re: stopgap fix for signal handling during restore_command  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: stopgap fix for signal handling during restore_command  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Fri, Feb 24, 2023 at 01:25:01PM +1300, Thomas Munro wrote:
> I think you should have a trailing \n when writing to stderr.

Oops.  I added that in v7.

> Here's that reproducer I speculated about (sorry I confused SIGQUIT
> and SIGTERM in my earlier email, ENOCOFFEE).  Seems to do the job, and
> I tested on a Linux box for good measure.  If you comment out the
> kill(), "check PROVE_TESTS=t/002_archiving.pl" works fine
> (demonstrating that that definition of system() works fine).  With the
> kill(), it reliably reaches 'TRAP: failed Assert("latch->owner_pid ==
> MyProcPid")' without your patch, and with your patch it avoids it.  (I
> believe glibc's system() could reach it too with the right timing, but
> I didn't try, my point being that the use of the OpenBSD system() here
> is only  because it's easier to grok and to wrangle.)

Thanks for providing the reproducer!  I am seeing the behavior that you
described on my Linux machine.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Вложения

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

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Allow logical replication to copy tables in binary format
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add LZ4 compression in pg_dump