On 2016-08-17 12:19:31 +0200, Magnus Hagander wrote:
> On Tue, Aug 16, 2016 at 9:54 PM, Andres Freund <andres@anarazel.de> wrote:
>
> > On 2016-07-12 19:05:16 -0400, Tom Lane 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.
> >
> > One approach would be to rename the file into something indicating it's
> > being deleted, before actually deleting it.
> >
> >
> That would be an option (IIRC if you open with FILE_SHARE_DELETE, it can
> also be renamed). But if we can track the delete when we try to open it and
> just treat it as "file does not exist", that seems cleaner.
I'm not sure what exactly you're suggesting. But isn't there the issue
that such an approach will not interoperate with external tools?