Re: parallelizing the archiver

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: parallelizing the archiver
Дата
Msg-id CA+TgmoaOh_3p0siYJ5ZpZt7Wsox5VnLYayvoyytKgQJJtqeUwQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: parallelizing the archiver  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: parallelizing the archiver  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: [RFC] speed up count(*)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [RFC] speed up count(*)