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
