Re: remove more archiving overhead

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, robertmhaas(at)gmail(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: remove more archiving overhead
Date: 2022-09-19 10:08:29
Message-ID: 7476bc05-3b8d-dab4-64e9-b569c54631d6@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhang Mingli 2022-09-19 10:19:07 Free list same_input_transnos in preprocess_aggref
Previous Message Peter Eisentraut 2022-09-19 09:25:59 Re: [RFC] building postgres with meson - v13