Re: remove more archiving overhead

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: remove more archiving overhead
Дата
Msg-id 20220803071617.GA3817792@rfd.leadboat.com
обсуждение исходный текст
Ответ на Re: remove more archiving overhead  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: remove more archiving overhead
Список pgsql-hackers
On Mon, Aug 01, 2022 at 10:02:19PM -0700, Nathan Bossart wrote:
> On Sat, Jul 30, 2022 at 11:51:56PM -0700, Noah Misch wrote:
> > Inviting the administrator to resolve things is more dangerous than just
> > returning true.  I recommend making this text more opinionated and simpler:
> > libraries must return true.  Alternately, if some library has found a good
> > reason to return false, this paragraph could give the reason.  I don't know of
> > such a reason, though.
> 
> Your suggestion seems reasonable to me.  I've attached a small patch.

> --- a/doc/src/sgml/backup.sgml
> +++ b/doc/src/sgml/backup.sgml
> @@ -691,11 +691,9 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0
>      system crashes before the server makes a durable record of archival success,
>      the server will attempt to archive the file again after restarting (provided
>      archiving is still enabled).  When an archive library encounters a
> -    pre-existing file, it may return <literal>true</literal> if the WAL file has
> +    pre-existing file, it should return <literal>true</literal> if the WAL file has
>      identical contents to the pre-existing archive and the pre-existing archive
> -    is fully persisted to storage.  Alternatively, the archive library may
> -    return <literal>false</literal> anytime a pre-existing file is encountered,
> -    but this will require manual action by an administrator to resolve.  If a
> +    is fully persisted to storage.  If a
>      pre-existing file contains different contents than the WAL file being
>      archived, the archive library <emphasis>must</emphasis> return
>      <literal>false</literal>.

Works for me.  Thanks.



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

Предыдущее
От: "shiy.fnst@fujitsu.com"
Дата:
Сообщение: RE: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
Следующее
От: Ronan Dunklau
Дата:
Сообщение: Fix gin index cost estimation