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

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file
Дата
Msg-id CABUevExG2xEQhsKuth8Z=ndiRbV7d1QtM6rNrG+CXYd5ut9GGg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file  (Andres Freund <andres@anarazel.de>)
Ответы Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file
Список pgsql-bugs
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.

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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Francisco Olarte
Дата:
Сообщение: Re: Help Me
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: jsonb_array_elements issue