Matthias Apitz <guru@unixarea.de> writes:
> El día Samstag, Juni 27, 2020 a las 07:21:21 -0700, Adrian Klaver escribió:
>>> 2020-06-27 10:23:02.631 CEST [18302] ERROR: canceling autovacuum task
>>> 2020-06-27 10:23:02.631 CEST [18302] CONTEXT: automatic analyze of table "testdump.public.idm_tasktab"
>> From what I understand they are occurring because the machine is to busy
>> doing the restore to get to the autovacuum task in a timely manner. So I
>> would say ignore and check back later to see that the autovacuum is working.
>> Given that it is ANALYZE that is being cancelled I would run a manual
>> ANALYZE after the restore is done to update the database statistics.
> The machine is a development server and no one was working on it (today
> is Saturday) apart of me. It has 4 modern and fast CPU,
I think more likely is this:
1. The restore run loads a lot of data into a table.
2. The autovacuum daemon notices all the inserts and starts an
auto-analyze run.
3. The restore run gets to the part where it tries to create indexes on
the table. This requires a ShareLock if memory serves, which conflicts
with the ShareUpdateExclusive lock that ANALYZE is holding. Rather than
making a foreground process wait for autovacuum, we kick autovacuum off
its lock by aborting the auto-analyze. Hence the message(s).
4. The un-analyzed inserts are still there, so some future autovacuum
cycle will try again.
In short, yeah, you should just ignore these log messages.
regards, tom lane
