Re: New autovacuum messages in postgres log after upgrade

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Benjamin Krajmalnik <kraj(at)servoyant(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: New autovacuum messages in postgres log after upgrade
Date: 2013-09-17 15:19:34
Message-ID: 1379431174.27898.YahooMailNeo@web162902.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Benjamin Krajmalnik <kraj(at)servoyant(dot)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 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?

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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Keith Ouellette 2013-09-17 15:53:52 Re: Too many WAL archive files
Previous Message Kevin Grittner 2013-09-17 12:43:50 Re: Dumping a database that is not accepting commands?