| From: | Mark Lai <mark(dot)lai(at)integrafec(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #15333: pg_dump error on large table -- "pg_dump: could not stat file...Unknown error" |
| Date: | 2018-08-21 14:46:52 |
| Message-ID: | CAM2yA55StRWChfQAyC6rdYc2ZDcpq5v83wE9QQwBETnmHVNjqA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(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
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melek JARRAYA | 2018-08-21 14:59:27 | Re: Not found indexed word |
| Previous Message | Andres Freund | 2018-08-21 14:45:48 | Re: BUG #15344: pg_proc.proisagg was removed incompatibly in PostgreSQL 11 |