Re: parallelizing the archiver - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: parallelizing the archiver
Date
Msg-id CABUevEx+7JD+gOBdemi_vjCVbH1GtTuAtHy40qx6K1STSWJXpw@mail.gmail.com
Whole thread Raw
In response to Re: parallelizing the archiver  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: parallelizing the archiver
List pgsql-hackers
On Tue, Oct 5, 2021 at 5:32 AM Bossart, Nathan <bossartn@amazon.com> wrote:
On 10/4/21, 8:19 PM, "Stephen Frost" <sfrost@snowman.net> wrote:
> It's also been discussed, at least around the water cooler (as it were
> in pandemic times- aka our internal slack channels..) that the existing
> archive command might be reimplemented as an extension using these.  Not
> sure if that's really necessary but it was a thought.  In any case,
> thanks for working on this!

Interesting.  I like the idea of having one code path for everything
instead of branching for the hook and non-hook paths.  Thanks for
sharing your thoughts.

I remember having had this discussion a few times, I think mainly with Stephen and David as well (but not on their internal slack channels :P).

I definitely think that's the way to go. It gives a single path for everything which makes it simpler in the most critical parts. And once you have picked an implementation other than it, you're now completely rid of the old implementation.  And of course the good old idea that having an extension already using the API is a good way to show that the API is in a good place. 

As much as I dislike our current interface in archive_command, and would like to see it go away completely, I do believe we need to ship something that has it - if nothing else then for backwards compatibility. But an extension like this would also make it easier to eventually, down the road, deprecate this solution. 

Oh, and please put said implementation in a better place than contrib :)

--

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Role Self-Administration
Next
From: Robert Haas
Date:
Subject: Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)