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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #15333: pg_dump error on large table -- "pg_dump: could not stat file...iso-8859-1 error"
Дата
Msg-id 13611.1534433145@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #15333: pg_dump error on large table -- "pg_dump: could not statfile...iso-8859-1 error"  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #15333: pg_dump error on large table -- "pg_dump: could notstat file...iso-8859-1 error"  (Mark Lai <mark.lai@integrafec.com>)
Список 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 по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15334: Partition elimination not working as expected when usingenum as partition key
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15335: Documentation is wrong about archive_command and existingfiles