From: Tom Lane <tgl@sss.pgh.pa.us>
To: mark.lai@integrafec.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15333: pg_dump error on large table -- "pg_dump: could not
 stat file...Unknown error"
In-reply-to: <153442391458.1505.9181095584291689853@wrigleys.postgresql.org>
References: <153442391458.1505.9181095584291689853@wrigleys.postgresql.org>
Comments: In-reply-to =?utf-8?q?PG_Bug_reporting_form?=
 <noreply@postgresql.org>
	message dated "Thu, 16 Aug 2018 12:51:54 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13610.1534433145.1@sss.pgh.pa.us>
Date: Thu, 16 Aug 2018 11:25:45 -0400
Message-ID: <13611.1534433145@sss.pgh.pa.us>
Precedence: bulk

=?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