|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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?
Amazon Web Services: https://aws.amazon.com
|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|