On Wed, Jul 13, 2016 at 8:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>>> On Tue, Jul 12, 2016 at 2:02 PM, <harukat@sraoss.co.jp> wrote:
>>>> It means file 16444 is in STATUS_DELETE_PENDING.
>
>> This file is probably being deleted by a checkpoint after some user
>> transaction marked it for removal (either because the relation was
>> dropped, or because it got a new relfilenode). I would say that the
>> file is not needed for the backup after all and pg_basebackup should
>> just ignore it.
>
> Yeah. The question is how do we distinguish that from cases that
> are less benign.
Indeed, recovery will be able to handle that case correctly, and the
file should be ignored in the base backup. It seems that
STATUS_DELETE_PENDING has always mapped to ERROR_ACCESS_DENIED in
NTSTATUS [1], which is definitely not the brightest idea ever because
this does not allow us to check if the access to a path is really
denied because of permissions.
Checking directly for STATUS_DELETE_PENDING would be the way to go,
likely with tweaks in basebackup.c. but like Takatsuka-san, I cannot
find anything around that would allow us to check for that.
[1]:
http://stackoverflow.com/questions/6680491/why-does-windows-return-error-access-denied-when-i-try-to-open-a-delete-pended-f
--
Michael