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 06:27:29 |
Message-ID: | 20230128062729.GA2570237@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 27, 2023 at 08:17:46PM -0800, Nathan Bossart wrote:
> 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.
Here is a work-in-progress patch set for adjusting the archive modules
interface. Is this roughly what you had in mind?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Attachment | Content-Type | Size |
---|---|---|
0001-s-ArchiveContext-ArchiveCallbacks.patch | text/x-diff | 2.8 KB |
0002-move-archive-module-exports-to-dedicated-header.patch | text/x-diff | 6.0 KB |
0003-restructure-archive-module-API.patch | text/x-diff | 6.9 KB |
0004-add-private-state-to-archive-modules.patch | text/x-diff | 8.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Ankit Kumar Pandey | 2023-01-28 08:21:09 | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |
Previous Message | Amit Kapila | 2023-01-28 05:56:08 | Re: Deadlock between logrep apply worker and tablesync worker |