Re: BUG #15767: Export fails 'worker process died unexpectedly' but no error in pg_dump
От | Tom Lane |
---|---|
Тема | Re: BUG #15767: Export fails 'worker process died unexpectedly' but no error in pg_dump |
Дата | |
Msg-id | 3366.1555519957@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #15767: Export fails 'worker process died unexpectedly' but no error in pg_dump (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: