Обсуждение: Reasons for not overwriting processed wal archives?

Поиск
Список
Период
Сортировка

Reasons for not overwriting processed wal archives?

От
Koen De Groote
Дата:

States:

> It is advisable to test your proposed archive command to ensure that it indeed does not overwrite an existing file, and that it returns nonzero status in this case.

Why exactly is this?

Assuming a situation in which the files, as part of the archive_command, are gzipped to their final location.

If the gzip fails, or stops halfway, perhaps due to a network issue... you're left with a file that isn't the full representation of the wal archive.

So it needs to be done again.

In cases where the file is simply moved, this can also occur. Wal size can be configured, and transfers might fail.

So they'd have to be done again.

If we test first for a file with that name being present, and refusing to go forward if there is... an admin is going to have to manually intervene and delete the half-finished file.

So isn't it better to just overwrite?

What scenario am I missing here?

Regards,
Koen

Re: Reasons for not overwriting processed wal archives?

От
"David G. Johnston"
Дата:
On Wednesday, May 18, 2022, Koen De Groote <kdg.dev@gmail.com> wrote:

States:

> It is advisable to test your proposed archive command to ensure that it indeed does not overwrite an existing file, and that it returns nonzero status in this case.

Why exactly is this?

Newer doc versions also say:

 This is an important safety feature to preserve the integrity of your archive in case of administrator error (such as sending the output of two different servers to the same archive directory).

David J.