Обсуждение: BUG #15767: Export fails 'worker process died unexpectedly' but no error in pg_dump

The following bug has been logged on the website:

Bug reference:      15767
Logged by:          Anna Muravieva
Email address:      ana-mur21s@yandex.ru
PostgreSQL version: 9.6.0
Operating system:   linux
Description:

Hello 

The problem is still there. Below the export message when the worker process
exits.
 
[DEBUG] pg_dump: dumping contents of table ".."
[DEBUG] pg_dump: dumping contents of table ".."
[DEBUG] pg_dump: [parallel archiver] could not obtain lock on relation
"collection_result"
This usually means that someone requested an ACCESS EXCLUSIVE lock on the
table after the pg_dump parent process had gotten the initial ACCESS SHARE
lock on the table.
[DEBUG] pg_dump: [parallel archiver] a worker process died unexpectedly
 
If later versions of pg_dump throw this as an "error" or "warning" or
something better, then maybe we can detect it as before by checking the exit
status of non-zero? Do we have way to detect it?
 
Thank you for help,
Anna



PG Bug reporting form <noreply@postgresql.org> writes:

 Bug reference: 15723
 Logged by: Anna Muravieva
 Email address: ana-mur21s@yandex.ru
 PostgreSQL version: 9.6.1
 Operating system: linux
 Description: 
 Hello
We have currently that issue. "worker process died unexpectedly" was
caused
Показать цитату целикомПоказать всю переписку
9.6.1 is pretty old, and since then we've fixed a number of bugs in
pg_dump and/or pg_restore that could cause problems in parallel restores.
Please update to current (9.6.12) and see if the problem still occurs.

If it is still there, you'd need to provide more details, like what SQL
command fails exactly.

                        regards, tom lane

PG Bug reporting form <noreply@postgresql.org> writes:
> [DEBUG] pg_dump: [parallel archiver] could not obtain lock on relation
> "collection_result"
> This usually means that someone requested an ACCESS EXCLUSIVE lock on the
> table after the pg_dump parent process had gotten the initial ACCESS SHARE
> lock on the table.
> [DEBUG] pg_dump: [parallel archiver] a worker process died unexpectedly

OK, that's an expected (if not very desirable) outcome if other processes
are taking exclusive locks concurrently with a parallel pg_dump run.
Right now the only answers are to be willing to retry the pg_dump run, or
not use parallel dump.
 
> If later versions of pg_dump throw this as an "error" or "warning" or
> something better, then maybe we can detect it as before by checking the exit
> status of non-zero? Do we have way to detect it?

You can't really tell it from any other pg_dump failure, no, except
by examining the error printout.

I posted some ideas about a possible way to remove this failure
condition at
https://www.postgresql.org/message-id/32178.1555515260@sss.pgh.pa.us
but that's just speculation at this point.  It's not really clear
that it'd remove all possible failures of this sort, anyway: a pg_dump
run is going to try to acquire access share locks on every table in
the database, more or less, and if you've got other things insisting
on access exclusive locks in parallel with that, the odds of deadlock
failures seem pretty high.

            regards, tom lane