Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file

On Wed, Aug 17, 2016 at 5:41 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2016-08-17 12:19:31 +0200, Magnus Hagander wrote:
> > On Tue, Aug 16, 2016 at 9:54 PM, Andres Freund <andres(at)anarazel(dot)de>
> wrote:
> >
> > > On 2016-07-12 19:05:16 -0400, Tom Lane wrote:
> > > > Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > > > >> On Tue, Jul 12, 2016 at 2:02 PM, <harukat(at)sraoss(dot)co(dot)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?
>

I'll have to admit I wasn't thinking of external tools. The external tools
would have to learn about pending-delete files themselves. So yeah, if we
care about those then renaming them to something predictable and then
instruct the third party tools to exclude such files would be a more
complete fix.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/