Re: stopgap fix for signal handling during restore_command

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <fujii(at)postgresql(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: stopgap fix for signal handling during restore_command
Date: 2023-02-24 04:33:23
Message-ID: 20230224043323.GA821522@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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/" 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:

Attachment Content-Type Size
v7-0001-Move-extra-code-out-of-the-Pre-PostRestoreCommand.patch text/x-diff 2.0 KB
v7-0002-Don-t-proc_exit-in-startup-s-SIGTERM-handler-if-f.patch text/x-diff 2.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-02-24 04:35:14 Re: Add LZ4 compression in pg_dump
Previous Message Peter Smith 2023-02-24 03:02:19 Re: Allow logical replication to copy tables in binary format