Re: parallelizing the archiver

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

In response to

Browse pgsql-hackers by date

  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