| From: | "Kevin Grittner" <kgrittn(at)mail(dot)com> |
|---|---|
| To: | "Kevin Grittner" <kgrittn(at)mail(dot)com>,"Jan Wieck" <JanWieck(at)Yahoo(dot)com> |
| Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>,"Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>, "Amit Kapila" <amit(dot)kapila(at)huawei(dot)com>, "Stephen Frost" <sfrost(at)snowman(dot)net>,"PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: autovacuum truncate exclusive lock round two |
| Date: | 2013-01-23 19:50:28 |
| Message-ID: | 20130123195028.119100@gmx.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2013-01-23 19:51:01 | Re: [PATCH] pg_isready (was: [WIP] pg_ping utility) |
| Previous Message | Phil Sorber | 2013-01-23 19:50:01 | Re: [PATCH] pg_isready (was: [WIP] pg_ping utility) |