| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, 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-21 20:19:56 |
| Message-ID: | CA+TgmoaOh_3p0siYJ5ZpZt7Wsox5VnLYayvoyytKgQJJtqeUwQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 19, 2021 at 2:50 PM Stephen Frost <sfrost(at)snowman(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-10-21 20:23:10 | Re: [RFC] speed up count(*) |
| Previous Message | Joe Conway | 2021-10-21 20:19:05 | Re: [RFC] speed up count(*) |