| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
| Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: archive modules |
| Date: | 2021-11-02 05:24:07 |
| Message-ID: | YYDLd7vsmrYHC+9C@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 02, 2021 at 01:43:54PM +0900, Fujii Masao wrote:
> On 2021/11/02 3:54, Bossart, Nathan wrote:
>> This thread is a continuation of the thread with the subject
>> "parallelizing the archiver" [0]. That thread had morphed into an
>> effort to allow creating archive modules, so I've created a new one to
>> ensure that this topic has the proper visibility.
>
> What is the main motivation of this patch? I was thinking that
> it's for parallelizing WAL archiving. But as far as I read
> the patch very briefly, WAL file name is still passed to
> the archive callback function one by one.
It seems to me that this patch is not moving into the right direction
implementation-wise (I have read the arguments about
backward-compatibility that led to the introduction of archive_library
and its shell mode), for what looks like a duplicate of
shared_preload_libraries but for an extra code path dedicated to the
archiver, where we could just have a hook instead? We have been
talking for some time now to make the archiver process more
bgworker-ish, so as we finish with something closer to what the
logical replication launcher is.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2021-11-02 05:34:57 | Re: Skipping logical replication transactions on subscriber side |
| Previous Message | Amit Kapila | 2021-11-02 04:57:15 | Re: Added schema level support for publication. |