Re: BUG #15333: pg_dump error on large table -- "pg_dump: could not stat file...Unknown error"

On Mon, Sep 5, 2022 at 3:16 PM Chanderprabh Jain <
chanderprabhjain95(at)gmail(dot)com> wrote:

> Hi All,
>
> Is there any update on this issue or how to fix this? Will replacing the
> pg_dump binaries with newer versions fix this or is it a fix in the
> underlying Windows OS image.?
>
> Thanks,
> Chanderprabh Jain
>
> On Mon, Sep 5, 2022 at 3:15 PM Mark Lai <mark(dot)lai(at)integrafec(dot)com> wrote:
>
>> Hi Michael,
>>
>> We are running the pg_dump on a NTFS file system on a Windows 2016 Server.
>>
>> Mark Lai
>>
>> On Sun, Aug 19, 2018 at 5:11 PM, Michael Paquier <michael(at)paquier(dot)xyz>
>> wrote:
>>
>>> On Fri, Aug 17, 2018 at 10:53:11AM -0400, Tom Lane wrote:
>>> > Mark Lai <mark(dot)lai(at)integrafec(dot)com> writes:
>>> >> I ran the dump on the large table with no jobs flag and got the same
>>> error.
>>> >> ...
>>> >> The dump was successful on a small table.
>>> >
>>> > Weird indeed. Can any Windows developers reproduce this and poke into
>>> it?
>>> >
>>> > I have a sneaking suspicion that this is related to Windows' known
>>> issues
>>> > with concurrently-opened files, but it's pretty hard to see why there
>>> > would be a dependency on the size of the file.
>>>
>>> When it comes to pg_dump, the error message reported seems to come from
>>> src/common/file_utils.c, in walkdir when processing links. On Windows
>>> we map lstat() to stat(), which is itself pgwin32_safestat().
>>>
>>> If you use pg_dump --no-sync, the error could be bypassed but that's
>>> hardly a fix. That could be a failure on GetFileAttributeEx(). Which
>>> file system are you using?
>>> --
>>> Michael
>>>
>>
>>