Re: remove more archiving overhead

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: remove more archiving overhead
Дата
Msg-id CA+Tgmob3engAzsLfR=aA=L_53T+PsA8wdP4x3FQ_s8rv1Lxpwg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: remove more archiving overhead  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
On Mon, Sep 19, 2022 at 6:08 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> I suspect what we are really trying to say here is
>
> ===
> Archiving setups (using either archive_command or archive_library)
> should be prepared for the rare case that an identical archive file is
> being archived a second time.  In such a case, they should compare that
> the source and the target file are identical and proceed without error
> if so.
>
> In some cases, it is difficult or impossible to configure
> archive_command or archive_library to do this.  In such cases, the
> archiving command or library should error like in the case for any
> pre-existing target file, and operators need to be prepared to resolve
> such cases manually.
> ===
>
> Is that correct?

I think it is. I think commit d263ced225bffe2c340175125b0270d1869138fe
made the documentation in this area substantially clearer than what we
had before, and I think that we could adjust that text to apply to
both archive libraries and archive commands relatively easily, so I'm
not really sure that we need to add text like what you propose here.

However, I also don't think it would be particularly bad if we did. An
advantage of that language is that it makes it clear what the
consequences are if you fail to follow the recommendation about
handling identical files. That may be helpful to users in
understanding the behavior of the system, and might even make it more
likely that they will include proper handling of that case in their
archive_command or archive_library.

"impossible" does seem like a bit of a strong word, though. I'd
recommend leaving that out.

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



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

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: HOT chain validation in verify_heapam()
Следующее
От: Robert Haas
Дата:
Сообщение: Re: remove more archiving overhead