Thread: BUG #15767: Export fails 'worker process died unexpectedly' but no error in pg_dump
BUG #15767: Export fails 'worker process died unexpectedly' but no error in pg_dump
From
PG Bug reporting form
Date:
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
Re: BUG #15767: Export fails 'worker process died unexpectedly' but no error in pg_dump
From
Tom Lane
Date:
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