Horton

Re: Weird failure with latches in curculio on v15

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, Fujii Masao <fujii@postgresql.org>, Nathan Bossart <nathandbossart@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-02-03T09:24:18Z
Lists: pgsql-hackers 
Hi, 

On February 3, 2023 9:19:23 AM GMT+01:00, Thomas Munro <thomas.munro@gmail.com> wrote:
>On Fri, Feb 3, 2023 at 9:09 PM Andres Freund <andres@anarazel.de> wrote:
>> Thinking about popen() suggests that we have a similar problem with COPY
>> FROM PROGRAM as we have in pgarch (i.e. not as bad as the startup
>> process issue, but still not great, due to
>> procsignal_sigusr1_handler()).
>
>A small mercy: while we promote some kinds of fatal-ish signals to
>group level with kill(-PID, ...), we don't do that for SIGUSR1 for
>latches or procsignals.

Not as bad, but we still do SetLatch() from a bunch of places that would be reached... 

Andres 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Commits

  1. Avoid calling proc_exit() in processes forked by system().

  2. Move extra code out of the Pre/PostRestoreCommand() section.

  3. Revert refactoring of restore command code to shell_restore.c

  4. Refactor code in charge of running shell-based recovery commands

  5. Clean up inconsistent use of fflush().

  6. Report wait events for local shell commands like archive_command.