Horton

Re: Weird failure with latches in curculio on v15

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Fujii Masao <fujii@postgresql.org>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-02-21T00:03:27Z
Lists: pgsql-hackers 
On Tue, Feb 14, 2023 at 09:47:55AM -0800, Nathan Bossart wrote:
> Here is a new version of the stopgap/back-branch fix for restore_command.
> This is more or less a rebased version of v4 with an added stderr message
> as Andres suggested upthread.

So, this thread has moved around many subjects, still we did not get
to the core of the issue which is what we should try to do to avoid
sporadic failures like what the top of the thread is mentioning.

Perhaps beginning a new thread with a patch and a summary would be
better at this stage?  Another thing I am wondering is if it could be
possible to test that rather reliably.  I have been playing with a few
scenarios like holding the system() call for a bit with hardcoded
sleep()s, without much success.  I'll try harder on that part..  It's
been mentioned as well that we could just move away from system() in
the long-term.
--
Michael

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.