Re: parallelizing the archiver - Mailing list pgsql-hackers

From Robert Haas
Subject Re: parallelizing the archiver
Date
Msg-id CA+TgmoaOh_3p0siYJ5ZpZt7Wsox5VnLYayvoyytKgQJJtqeUwQ@mail.gmail.com
Whole thread Raw
In response to Re: parallelizing the archiver  (Stephen Frost <sfrost@snowman.net>)
Responses Re: parallelizing the archiver  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Oct 19, 2021 at 2:50 PM Stephen Frost <sfrost@snowman.net> wrote:
> I keep seeing this thrown around and I don't quite get why we feel this
> is the case.  I'm not completely against trying to maintain backwards
> compatibility, but at the same time, we just went through changing quite
> a bit around in v12 with the restore command and that's the other half
> of this.  Why are we so concerned about backwards compatibility here
> when there was hardly any complaint raised about breaking it in the
> restore case?

There are 0 references to restore_command in the v12 release notes.
Just in case you had the version number wrong in this email, I
compared the documentation for restore_command in v10 to the
documentation in v14. The differences seem to be only cosmetic. So I'm
not sure what functional change you think we made. It was probably
less significant than what was being discussed here in regards to
archive_command.

Also, more to the point, when there's a need to break backward
compatibility in order to get some improvement, it's worth
considering, but here there just isn't.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: [RFC] speed up count(*)
Next
From: Robert Haas
Date:
Subject: Re: [RFC] speed up count(*)