Re: error messages (autovaccum canceled and syntax errors) while loading a DUMP
От | Tom Lane |
---|---|
Тема | Re: error messages (autovaccum canceled and syntax errors) while loading a DUMP |
Дата | |
Msg-id | 145169.1593281251@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: error messages (autovaccum canceled and syntax errors) whileloading a DUMP (Matthias Apitz <guru@unixarea.de>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: