Re: autovacuum truncate exclusive lock round two - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: autovacuum truncate exclusive lock round two
Date
Msg-id 20130123195028.119100@gmx.com
Whole thread Raw
In response to autovacuum truncate exclusive lock round two  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Kevin Grittner wrote:

> Applied with trivial editing, mostly from a pgindent run against
> modified files.

Applied back as far as 9.0. Before that code didn't match well
enough for it to seem safe to apply without many hours of
additional testing.

I have confirmed occurences of this problem at least as far back as
9.0 in the wild, where it is causing performance degradation severe
enough to force users to stop production usage long enough to
manually vacuum the affected tables. The use case is a lot like
what Jan described, where PostgreSQL is being used for high volume
queuing. When there is a burst of activity which increases table
size, and then the queues are drained back to a normal state, the
problem shows up.

-Kevin



pgsql-hackers by date:

Previous
From: Phil Sorber
Date:
Subject: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)