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
>
>