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"
Date: Thu, 16 Aug 2018 11:25:45 -0400
Message-ID: <13611.1534433145@sss.pgh.pa.us> (raw)
In-Reply-To: <153442391458.1505.9181095584291689853@wrigleys.postgresql.org>
References: <153442391458.1505.9181095584291689853@wrigleys.postgresql.org>
=?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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, mark.lai@integrafec.com, 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: <13611.1534433145@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox