Re: WAL-related tools and .paritial WAL file

On Thu, Jul 2, 2015 at 3:48 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Thu, Jul 2, 2015 at 2:06 PM, Fujii Masao wrote:
>> I implemented the patch accordingly. Patch attached.
>
> Cool, thanks.
>
> I have done some tests with pg_archivecleanup, and it works as
> expected, aka if I define a backup file, the backup file as well as
> the segments equal or newer than it remain. It works as well when
> defining a .partial file. I have done as well some testing with
> pg_resetxlog and the partial segment gets removed.

Thanks for testing the patch!

Attached is the updated version of the patch.

> Here are some comments:
> 1) pgarchivecleanup.sgml needs to be updated:
> In this mode, if you specify a <filename>.backup</> file name, then
> only the file prefix
> Here we should mention that it is also the case of a .partial file.

Applied.

> 2)
> - * restartWALFileName is a .backup filename, make sure we use the prefix
> - * of the filename, otherwise we will remove wrong files since
> + * restartWALFileName is a .partial or .backup filename, make
> sure we use
> + * the prefix of the filename, otherwise we will remove wrong
> files since
> * 000000010000000000000010.00000020.backup is after
> * 000000010000000000000010.
> Shouldn't this be made clearer as well regarding .partial files? For
> example with a comment like that:
> otherwise we will remove wrong files since
> 000000010000000000000010.00000020.backup or
> 000000010000000000000010.00000020.partial are after
> 000000010000000000000010. Simply not mentioning those file names
> directly is fine for me.

Applied.

> 3) Something not caused by this patch that I just noticed... But
> pg_resetxlog does not remove .backup files in pg_xlog. Shouldn't they
> get moved away as well?

pg_resetxlog doesn't remove also .history file in pg_xlog. Those remaining
.backup and .history files are harmless after pg_resetxlog is executed.
So I don't think that it's required to remove them. Of course we can do that,
but some existing applications might depend on the current behavior...
So unless there is strong reason to do that, I'd like to let it as it is.

Regards,

--
Fujii Masao