Re: autovacuum truncate exclusive lock round two

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: autovacuum truncate exclusive lock round two
Дата
Msg-id 20130123195028.119100@gmx.com
обсуждение исходный текст
Ответ на autovacuum truncate exclusive lock round two  (Jan Wieck <JanWieck@Yahoo.com>)
Список 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 по дате отправления:

Предыдущее
От: Phil Sorber
Дата:
Сообщение: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)