Re: recovery modules

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2023-01-30T19:38:20Z
Lists: pgsql-hackers
On Mon, Jan 30, 2023 at 04:51:38PM +0900, Michael Paquier wrote:
> Now, I find this part, where we use a double pointer to allow the
> module initialization to create and give back a private area, rather
> confusing, and I think that this could be bug-prone, as well.  Once
> you incorporate some data within the set of callbacks, isn't this
> stuff close to a "state" data, or just something that we could call
> only an "ArchiveModule"?  Could it make more sense to have
> _PG_archive_module_init return a structure with everything rather than
> a separate in/out argument?  Here is the idea, simply:
> typedef struct ArchiveModule {
> 	ArchiveCallbacks *routines;
> 	void *private_data;
> 	/* Potentially more here, like some flags? */
> } ArchiveModule;

Yeah, we could probably invent an ArchiveModuleContext struct.  I think
this is similar to how LogicalDecodingContext is used.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



Commits

  1. Redesign archive modules

  2. Remove uses of AssertVariableIsOfType() obsoleted by f2b73c8

  3. Rename contrib module basic_archive to basic_wal_module

  4. Refactor code for restoring files via shell commands

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