Re: Weird failure with latches in curculio on v15
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, 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-08T22:25:54Z
Lists: pgsql-hackers
On Wed, Feb 08, 2023 at 04:24:15PM -0500, Robert Haas wrote: > On Wed, Feb 8, 2023 at 12:43 PM Nathan Bossart <nathandbossart@gmail.com> wrote: >> I think this could be a good approach if we decide not to bake too much >> into PostgreSQL itself (e.g., such as creating multiple archive workers >> that each call out to the module). Archive module authors would >> effectively need to write their own archiver processes. That sounds super >> flexible, but it also sounds like it might be harder to get right. > > Yep. That's a problem, and I'm certainly open to better ideas. > > However, if we assume that the archive module is likely to be doing > something like juggling a bunch of file descriptors over which it is > speaking HTTP, what other model works, really? It might be juggling > those file descriptors indirectly, or it might be relying on an > intermediate library like curl or something from Amazon that talks to > S3 or whatever, but only it knows what resources it's juggling, or > what functions it needs to call to manage them. On the other hand, we > don't really need a lot from it. We need it to CHECK_FOR_INTERRUPTS() > and handle that without leaking resources or breaking the world in > some way, and we sort of need it to, you know, actually archive stuff, > but apart from that I guess it can do what it likes (unless I'm > missing some other important function of the archiver?). > > It's probably a good idea if the archiver function returns when it's > fully caught up and there's no more work to do. Then we could handle > decisions about hibernation in the core code, rather than having every > archive module invent its own way of doing that. But when there's work > happening, as far as I can see, the archive module needs to have > control pretty nearly all the time, or it's not going to be able to do > anything clever. > > Always happy to hear if you see it differently.... These are all good points. Perhaps there could be a base archiver implementation that shell_archive uses (and that other modules could use if desired, which might be important for backward compatibility with the existing callbacks). But if you want to do something fancier than archiving sequentially, you could write your own. In any case, I'm not really wedded to any particular approach at the moment, so I am likewise open to better ideas. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Commits
-
Avoid calling proc_exit() in processes forked by system().
- d0e7f95b4845 11.22 landed
- e2e16904224a 12.17 landed
- ac1dfc303d0e 13.13 landed
- 54fc9dca5b10 14.10 landed
- c9265ae80b6a 15.5 landed
- ee06199fcb0a 16.1 landed
- 97550c071197 17.0 landed
-
Move extra code out of the Pre/PostRestoreCommand() section.
- 882e522d6468 15.5 landed
- d1c56ad37b96 16.1 landed
- 8fb13dd6ab5b 17.0 landed
-
Revert refactoring of restore command code to shell_restore.c
- 2f6e15ac93c5 16.0 landed
-
Refactor code in charge of running shell-based recovery commands
- 9a740f81eb02 16.0 cited
-
Clean up inconsistent use of fflush().
- 7fed801135ba 16.0 cited
-
Report wait events for local shell commands like archive_command.
- 1b06d7bac901 15.0 cited