Matthias Apitz <guru@xxxxxxxxxxx> 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
