Re: remove more archiving overhead

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: remove more archiving overhead
Дата
Msg-id 7476bc05-3b8d-dab4-64e9-b569c54631d6@enterprisedb.com
обсуждение исходный текст
Ответ на Re: remove more archiving overhead  (Noah Misch <noah@leadboat.com>)
Ответы Re: remove more archiving overhead  (Noah Misch <noah@leadboat.com>)
Re: remove more archiving overhead  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 18.09.22 09:13, Noah Misch wrote:
>>> This documentation change only covers archive_library.  How are users of
>>> archive_command supposed to handle this?
>>
>> I believe users of archive_command need to do something similar to what is
>> described here.  However, it might be more reasonable to expect
>> archive_command users to simply return false when there is a pre-existing
>> file, as the deleted text notes.  IIRC that is why I added that sentence
>> originally.
> 
> What makes the answer for archive_command diverge from the answer for
> archive_library?

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?



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [RFC] building postgres with meson - v13
Следующее
От: Zhang Mingli
Дата:
Сообщение: Free list same_input_transnos in preprocess_aggref