Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file
От | Kevin Grittner |
---|---|
Тема | Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file |
Дата | |
Msg-id | CACjxUsNKKcb5JRX_Ww1o-ReW0oMth_-hAXuHxJ1hPQnHd1=_uQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-bugs |
On Thu, Oct 6, 2016 at 12:20 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > 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. Any chance that an OS snapshot of the volume was being taken at the time of the error? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: