From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallelizing the archiver |
Date: | 2021-10-01 18:05:36 |
Message-ID: | 512BF1DA-48E5-4F05-B2E9-2286F59CB037@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/29/21, 9:49 PM, "Bossart, Nathan" <bossartn(at)amazon(dot)com> wrote:
> I'm sure there are other ways to approach this, but I thought I'd give
> it a try to see what was possible and to get the conversation started.
BTW I am also considering the background worker approach that was
mentioned upthread. My current thinking is that the backup extension
would define a special background worker that communicates with the
archiver via shared memory. As noted upthread, this would enable
extension authors to do whatever batching, parallelism, etc. that they
want, and it should also prevent failures from taking down the
archiver process. However, this approach might not make sense for
things like recovery_end_command that are only executed once. Maybe
it's okay to leave that one alone for now.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-10-01 18:07:42 | Re: PATH manipulation in 001_libpq_pipeline.pl fails on windows |
Previous Message | Jaime Casanova | 2021-10-01 17:49:24 | Re: 2021-09 Commitfest |