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

From Tom Lane
Subject Re: BUG #15333: pg_dump error on large table -- "pg_dump: could not stat file...iso-8859-1 error"
Date
Msg-id 13611.1534433145@sss.pgh.pa.us
Whole thread Raw
In response to BUG #15333: pg_dump error on large table -- "pg_dump: could not statfile...iso-8859-1 error"  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #15333: pg_dump error on large table -- "pg_dump: could notstat file...iso-8859-1 error"
List pgsql-bugs
=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.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


pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15334: Partition elimination not working as expected when usingenum as partition key
Next
From: PG Bug reporting form
Date:
Subject: BUG #15335: Documentation is wrong about archive_command and existingfiles