Re: remove more archiving overhead

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: remove more archiving overhead
Дата
Msg-id CA+TgmoZ5=rndPZHKQiXk3x6Fi16+Sob6kU=8Lh8nJnMrrkpvfg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: remove more archiving overhead  (Noah Misch <noah@leadboat.com>)
Ответы Re: remove more archiving overhead  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Mon, Sep 19, 2022 at 10:39 AM Noah Misch <noah@leadboat.com> wrote:
> I wanted it to stop saying anything like the second paragraph, hence commit
> d263ced.  Implementing a proper archiving setup is not especially difficult,
> and inviting the operator to work around a wrong implementation invites
> damaging mistakes under time pressure.

I agree wholeheartedly with the second sentence. I do think that we
need to be a little careful not to be too prescriptive. Telling people
what they have to do when they don't really have to do it often leads
to non-compliance. It can be more productive to spell out the precise
consequences of non-compliance, so I think Peter's proposal has some
merit. On the other hand, I don't see any real problem with the
current language, either.

Unfortunately, no matter what we do here, it is not likely that we'll
soon be able to eliminate the phenomenon where people use a buggy
home-grown archive_command, both because we've been encouraging that
in our documentation for a very long time, and also because the people
who are most likely to do something half-baked here are probably the
least likely to actually read the updated documentation.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: remove more archiving overhead
Следующее
От: Florin Irion
Дата:
Сообщение: pg_create_logical_replication_slot argument incongruency