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
-
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