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