Обсуждение: New autovacuum messages in postgres log after upgrade
During a maintenance window, we upgraded our systems to Postgres 9.0.13 from 9.0.3 running on FreeBSD 8.1 amd64.
When we restarted the postgres server, I notices, and continue to notice, a recurrence of messages in the log.
2013-09-16 21:15:58 MDT LOG: automatic vacuum of table "ishield.public.tbltmptests": could not (re)acquire exclusive lock for truncate scan
2013-09-16 21:15:59 MDT LOG: automatic vacuum of table "ishield.public.tbltmptests": could not (re)acquire exclusive lock for truncate scan
2013-09-16 21:16:00 MDT LOG: automatic vacuum of table "ishield.public.tbltmptests": could not (re)acquire exclusive lock for truncate scan
The tables on which I am seeing this messages are essentially temporary work tables into which we insert records, which are processed by triggers, and then deleted.
Performance of the system does not seem to have been affected by the upgrade.
Is this simply caused by a higher level of verbosity in the autovaccum logging, as a result of the autovacuum fix in 9.0.12?
I did notice that while previously I had issues with vacuum full not being able to run due to not finding an entry in toast tables, this appears to have been resolved.
Thanks in advance,
Benjamin
Benjamin Krajmalnik <kraj@servoyant.com> wrote: > During a maintenance window, we upgraded our systems to Postgres > 9.0.13 from 9.0.3 running on FreeBSD 8.1 amd64. > When we restarted the postgres server, I notices, and continue to > notice, a recurrence of messages in the log. > > 2013-09-16 21:15:58 MDT LOG: automatic vacuum of table "ishield.public.tbltmptests": could not (re)acquire exclusive lockfor truncate scan > 2013-09-16 21:15:59 MDT LOG: automatic vacuum of table "ishield.public.tbltmptests": could not (re)acquire exclusive lockfor truncate scan > 2013-09-16 21:16:00 MDT LOG: automatic vacuum of table "ishield.public.tbltmptests": could not (re)acquire exclusive lockfor truncate scan > > The tables on which I am seeing this messages are essentially > temporary work tables into which we insert records, which are > processed by triggers, and then deleted. > Performance of the system does not seem to have been affected by > the upgrade. > Is this simply caused by a higher level of verbosity in the > autovaccum logging, as a result of the autovacuum fix in 9.0.12? Yes, table truncation after a large number of deletes is now smarter, getting more done with less effort and blocking. This message, which was useful for developing the fix, made it into production at the LOG level. In the next minor release it will be changed to the DEBUG level to avoid cluttering the log with entries about routine activities. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company