Re: BUG #15333: pg_dump error on large table -- "pg_dump: could notstat file...iso-8859-1 error" - Mailing list pgsql-bugs

From Mark Lai
Subject Re: BUG #15333: pg_dump error on large table -- "pg_dump: could notstat file...iso-8859-1 error"
Date
Msg-id CAM2yA55StRWChfQAyC6rdYc2ZDcpq5v83wE9QQwBETnmHVNjqA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #15333: pg_dump error on large table -- "pg_dump: could notstat file...iso-8859-1 error"  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #15333: pg_dump error on large table -- "pg_dump: could not stat file...iso-8859-1 error"  (Chanderprabh Jain <chanderprabhjain95@gmail.com>)
List pgsql-bugs
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@paquier.xyz> wrote:
On Fri, Aug 17, 2018 at 10:53:11AM -0400, Tom Lane wrote:
> Mark Lai <mark.lai@integrafec.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

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #15344: pg_proc.proisagg was removed incompatibly inPostgreSQL 11
Next
From: "Melek JARRAYA"
Date:
Subject: Re: Not found indexed word