Re: recovery modules

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-04-06T00:34:45Z
Lists: pgsql-hackers
On Fri, Feb 17, 2023 at 11:41:32AM -0800, Andres Freund wrote:
> I don't fully now, it's not entirely clear to me what the goals here were. I
> think you'd likely need to do a bit of infrastructure work to do this
> sanely. So far we just didn't have the need to handle files being released in
> a way like you want to do there.
> 
> I suspect a good direction would be to use resource owners. Add a separate set
> of functions that release files on resource owner release. Most of the
> infrastructure is there already, for temporary files
> (c.f. OpenTemporaryFile()).

Yes, perhaps.  I've had good experience with these when it comes to
avoid leakages when releasing resources, particularly for resources
allocated by external libraries (cough, OpenSSL, cough).  And there
was some work to make these more scalable, for example.

At this stage of the CF, it seems pretty clear to me that this should
be pushed to v17, so moved to next CF.
--
Michael

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