Re: stopgap fix for signal handling during restore_command - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: stopgap fix for signal handling during restore_command
Date
Msg-id 20230224043323.GA821522@nathanxps13
Whole thread Raw
In response to Re: stopgap fix for signal handling during restore_command  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: stopgap fix for signal handling during restore_command
List 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

Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Allow logical replication to copy tables in binary format
Next
From: Michael Paquier
Date:
Subject: Re: Add LZ4 compression in pg_dump