From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: recovery modules |
Date: | 2023-01-28 04:17:46 |
Message-ID: | 20230128041746.GA2288302@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> I was wondering why we implement "shell" via a separate mechanism from
> restore_library. I.e. a) why doesn't restore_library default to 'shell',
> instead of an empty string, b) why aren't restore_command et al implemented
> using a restore module.
I think that's the long-term idea. For archive modules, there were
concerns about backward compatibility [0].
[0] https://postgr.es/m/CABUevEx8cKy%3D%2BYQU_3NaeXnZV2bSB7Lk6EE%2B-FEcmE4JO4V1hg%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-28 04:18:39 | Re: lockup in parallel hash join on dikkop (freebsd 14.0-current) |
Previous Message | Andres Freund | 2023-01-28 04:11:38 | Re: Something is wrong with wal_compression |