Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file
Date
Msg-id CAB7nPqQ4EQ4-HpjKT_UPp-3xZCnm2pQK-OK_b75uqXqhKz9JNg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file  (Michael Paquier <michael.paquier@gmail.com>)
Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file  (Kevin Grittner <kgrittn@gmail.com>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #14343: UPSERT (ON CONFLICT) doesn't check ON CONFLICT constraint first
Next
From: Michael Paquier
Date:
Subject: Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file