Re: recovery modules
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org
Date: 2023-01-28T06:27:29Z
Lists: pgsql-hackers
Attachments
- 0001-s-ArchiveContext-ArchiveCallbacks.patch (text/x-diff)
On Fri, Jan 27, 2023 at 08:17:46PM -0800, Nathan Bossart wrote: > On Fri, Jan 27, 2023 at 05:55:42PM -0800, Andres Freund wrote: >> On 2023-01-27 16:59:10 -0800, Nathan Bossart wrote: >>> I think it would be weird for the archive module and >>> recovery module interfaces to look so different, but if that's okay, I can >>> change it. >> >> I'm a bit sad about the archive module case - I wonder if we should change it >> now, there can't be many users of it out there. And I think it's more likely >> that we'll eventually want multiple archiving scripts to run concurrently - >> which will be quite hard with the current interface (no private state). > > I'm open to that. IIUC it wouldn't require too many changes to existing > archive modules, and if it gets us closer to batching or parallelism, it's > probably worth doing sooner than later. Here is a work-in-progress patch set for adjusting the archive modules interface. Is this roughly what you had in mind? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Commits
-
Redesign archive modules
- 35739b87dcfe 16.0 landed
-
Remove uses of AssertVariableIsOfType() obsoleted by f2b73c8
- 30b789eafed2 16.0 landed
-
Rename contrib module basic_archive to basic_wal_module
- 0ad3c60caf5f 16.0 landed
-
Refactor code for restoring files via shell commands
- 14bdb3f13de1 16.0 landed
-
Refactor code in charge of running shell-based recovery commands
- 9a740f81eb02 16.0 landed