Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file
От | Michael Paquier |
---|---|
Тема | Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file |
Дата | |
Msg-id | CAB7nPqQ4EQ4-HpjKT_UPp-3xZCnm2pQK-OK_b75uqXqhKz9JNg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING
file
Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file |
Список | pgsql-bugs |
On Thu, Sep 29, 2016 at 11:34 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Michael Paquier wrote: > >> I gave this bug another try and let Windows run for some time but I >> cannot reproduce the original failure even with manual checkpointing >> and aggressive checkpoint_timeout, while truncating relations heavily >> with pgbench to enforce the deletion of relfilenodes. To all, do you >> think that having a large relfilenode file matters to trigger this >> issue? > > Hmm, perhaps with a larger file the OS spends more time shredding the > file or something like that? Perhaps there are filesystem options > involved, for instance. I have been digging around that, but could not find out any options that would delay the file deletion after it has been requested. As pg_basebackup grabs automatically all the files in PGDATA, I have as well tried to use thousands of dummy files up to 1MB, as well as huge files ("fsutil file createnew" is your friend), deleting them manually to force the stat() calls to be unhappy be still I could not reproduce it... If somebody has better ideas I am open. -- Michael
В списке pgsql-bugs по дате отправления: