| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | mark(dot)lai(at)integrafec(dot)com |
| Cc: | 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-16 15:25:45 |
| Message-ID: | 13611.1534433145@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> When I pg_dump a large table (> 35 GB), I get the following error message:
> pg_dump: could not stat file
> "O:\postgres-server3\test#test#large_test/2793.dat.gz": Unknown error
> The dump however appears to restore correctly.
Hm, I assume this shows up just at the end of the dump run?
The only plausible match for that error string is in the
fsync_dir_recurse() processing that tries to force all the output files
down to disk before reporting that the dump is complete. As long as
you don't have an OS crash right afterwards, failure to fsync is
harmless. Still, it's weird.
Does it vary with the size of the dumped table? What if you remove
the parallelism (no --jobs option)?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2018-08-16 16:10:00 | BUG #15335: Documentation is wrong about archive_command and existing files |
| Previous Message | PG Bug reporting form | 2018-08-16 14:05:17 | BUG #15334: Partition elimination not working as expected when using enum as partition key |