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