Re: BUG #5946: Long exclusive lock taken by vacuum (not full)

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Дата
Msg-id AANLkTimiCkmZ5NL=iPUG08TRAd-OJp_M1sR2SCm6c2BL@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #5946: Long exclusive lock taken by vacuum (not full)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #5946: Long exclusive lock taken by vacuum (not full)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Fri, Mar 25, 2011 at 11:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Maxim Boguk" <Maxim.Boguk@gmail.com> writes:
>> In my case vacuum tried to truncate last 10-15GB from 100Gb relation, and
>> each time (3) it was cost 10+ minutes of service downtime (because that
>> table was completely locked).
>
>> Is =A0that correct behaviour? Are here any way to speedup that process o=
r at
>> least allow read-only queries during that time?
>
> Use autovacuum --- if there's something that wants to access the table,
> autovac will get kicked off the lock. =A0(Of course, the table may never
> get truncated then, but maybe you don't care.)

I could see this turning out somewhat unhappily...

If there's almost always something that wants to access the table,
which would be hardly surprising, in view that the table is being
updated with sufficient regularity that it's got 10GB+ of dead space
at the end, then you're eventually going to *HAVE* to vacuum it.
Transaction rollover, and what not.

The piper will need to get paid, eventually :-(.

So I don't think leaving it to autovacuum quite suffices, because
eventually there's a 10 minute "glut", or more, that needs to get
paid.
--=20
http://linuxfinances.info/info/linuxdistributions.html

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Alex Lai
Дата:
Сообщение: Re: postgres 9 streaming replication
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)