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 по дате отправления: