agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Nathan Bossart <nathandbossart@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@postgresql.org
Subject: Re: recovery modules
Date: Thu, 16 Feb 2023 13:58:10 -0800
Message-ID: <20230216215810.GA2356244@nathanxps13> (raw)
In-Reply-To: <20230216211754.7z2v5i7gh3xahikl@awork3.anarazel.de>
References: <Y+nopoSsxz0t3Orz@paquier.xyz>
<20230213225647.GA1102783@nathanxps13>
<20230213233733.dsiaxtbr5nvskq46@awork3.anarazel.de>
<20230214005558.GA1145703@nathanxps13>
<20230214010237.GA1187708@nathanxps13>
<Y+x93YToABJ9Rpxl@paquier.xyz>
<20230215184407.GA1481856@nathanxps13>
<20230216192956.mhi6uiakchkolpki@awork3.anarazel.de>
<20230216201512.GA2074541@nathanxps13>
<20230216211754.7z2v5i7gh3xahikl@awork3.anarazel.de>
On Thu, Feb 16, 2023 at 01:17:54PM -0800, Andres Freund wrote:
> On 2023-02-16 12:15:12 -0800, Nathan Bossart wrote:
>> On Thu, Feb 16, 2023 at 11:29:56AM -0800, Andres Freund wrote:
>> > On 2023-02-15 10:44:07 -0800, Nathan Bossart wrote:
>> >> @@ -144,10 +170,12 @@ basic_archive_configured(void)
>> >> * Archives one file.
>> >> */
>> >> static bool
>> >> -basic_archive_file(const char *file, const char *path)
>> >> +basic_archive_file(ArchiveModuleState *state, const char *file, const char *path)
>> >> {
>> >> sigjmp_buf local_sigjmp_buf;
>> >
>> > Not related the things changed here, but this should never have been pushed
>> > down into individual archive modules. There's absolutely no way that we're
>> > going to keep this up2date and working correctly in random archive
>> > modules. And it would break if archive modules are ever called outside of
>> > pgarch.c.
>>
>> Yeah. IIRC I did briefly try to avoid this, but the difficulty was that
>> each module will have its own custom cleanup logic.
>
> It can use PG_TRY/CATCH for that, if the top-level sigsetjmp is in pgarch.c.
> Or you could add a cleanup callback to the API, to be called after the
> top-level cleanup in pgarch.c.
Yeah, that seems workable.
> I'm quite baffled by:
> /* Close any files left open by copy_file() or compare_files() */
> AtEOSubXact_Files(false, InvalidSubTransactionId, InvalidSubTransactionId);
>
> in basic_archive_file(). It seems *really* off to call AtEOSubXact_Files()
> completely outside the context of a transaction environment. And it only does
> the thing you want because you pass parameters that aren't actually valid in
> the normal use in AtEOSubXact_Files(). I really don't understand how that's
> supposed to be ok.
Hm. Should copy_file() and compare_files() have PG_FINALLY blocks that
attempt to close the files instead? What would you recommend?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
view thread (90+ messages) latest in thread
Message-ID: <20230216215810.GA2356244@nathanxps13>
Permalink: ../20230216215810.GA2356244@nathanxps13/
Also on: postgresql.org/message-id/20230216215810.GA2356244@nathanxps13
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, andres@anarazel.de, robertmhaas@gmail.com, michael@paquier.xyz
Subject: Re: recovery modules
In-Reply-To: <20230216215810.GA2356244@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox