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 <alvhe...@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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
