Re: Autovacuum different in 9.2.4?

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Autovacuum different in 9.2.4?
Date: 2013-08-05 19:46:19
Message-ID: 20130805194619.GB27382@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joshua D. Drake escribió:

> On 08/05/2013 12:13 PM, Jeff Janes wrote:
>
> >There should be no change in usage, unless you were taking some heroic
> >methods to overcome the problems and can now discontinue them.
>
> That is what is confusing me, I could be cracked but messages like these:
>
> automatic vacuum of table "pg_catalog.pg_attribute": could not
> (re)acquire exclusive lock for truncate scan
>
> Seem to be new?

Yeah, those are new. In the old code, trying to truncate the free pages
at the end of a table (which requires an ACCESS EXCLUSIVE lock on the
table) could lock other processes out of that table. The new code
instead tries to handle this gracefully by giving up the lock if some
other process is trying to access the table. The result is that a few
free pages might be left over after vacuuming the table. Not a big
deal, normally, unless you're really short on disk space.

There was discussion about autovacuum being tweaked so that it would
reattempt to truncate those free pages in a future pass. I don't know
if this was done or not.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-08-05 19:53:01 Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters
Previous Message Tom Lane 2013-08-05 19:44:30 Re: Moving 'hot' pages from buffer pool to heap