Re: vac truncation scan problems

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: vac truncation scan problems
Дата
Msg-id CAMkU=1xmTEiaY=5oMHsSQo5vd9V1Ze4kNLL0qN2eH0P_GXOaYw@mail.gmail.com
обсуждение исходный текст
Ответ на vac truncation scan problems  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: vac truncation scan problems  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: vac truncation scan problems  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Mon, Mar 30, 2015 at 8:54 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
After freeing up the rows at the end of the table so it is eligible for truncation, then running a manual VACUUM to actually release the space, I kept running into the problem that the truncation scan was consistently suspended and then aborted due to a conflicting lock requested/held.  

But the perversity is that that conflicting lock request can only be coming, as far as I can tell, from the autovac process.  I'm not sure how this happens, as I thought autovac never waited for locks but only obtained one if it were instantaneously available, but that it is the only explanation I can think of.

I'm not seeing this in 9.4, but I'm not sure how deterministic it is so maybe that is just luck.


It looks like the culprit is this:

commit 0d831389749a3baaced7b984205b9894a82444b9
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:   Wed Mar 18 11:52:33 2015 -0300

    Rationalize vacuuming options and parameters

I'd guess the autovac nature of the autovac process is getting lost in there where, but I don't see where.

Cheers,

Jeff

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

Предыдущее
От: Jehan-Guillaume de Rorthais
Дата:
Сообщение: Re: Maximum number of WAL files in the pg_xlog directory
Следующее
От: Jehan-Guillaume de Rorthais
Дата:
Сообщение: Re: Maximum number of WAL files in the pg_xlog directory