Re: BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze
От | Jerry Gamache |
---|---|
Тема | Re: BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze |
Дата | |
Msg-id | 4B72D6B6.4040900@idilia.com обсуждение исходный текст |
Ответ на | Re: BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
I was also surprised that table_y seemed to be involved. This is not a typo. Might be caused by a FK constraint between table_y and table_x. From the logs, the autovacuum on table_x was canceled before the one on table_y, but the restore only resumed after the autovacuum on table_y was canceled. It is possible (but I cannot confirm) that the autovacuum thread on table_x was blocked for a while after the cancellation message was written to the log. I added timestamps to log_line_prefix to be able to give more details if this happens again. Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > >> Jerry Gamache wrote: >> >>> The restore resumed while I was writing this report, and I saw these new >>> entries in the logs: >>> >>> ERROR: canceling autovacuum task >>> CONTEXT: automatic analyze of table "database1.public.table_y" >>> ERROR: canceling autovacuum task >>> CONTEXT: automatic analyze of table "database1.public.table_y" >>> > > >> This is what I would have expected to happen almost immediately ... what >> are your autovacuum settings? And what's your deadlock timeout? >> > > The other details showed the blockage as being on table_x though. > Was that a typo in obscuring the details, or did the cancel really > happen on an unrelated table? > > regards, tom lane > >
В списке pgsql-bugs по дате отправления: