Re: lazy vacuum and AccessExclusiveLock

Поиск
Список
Период
Сортировка
От Jaromír Talíř
Тема Re: lazy vacuum and AccessExclusiveLock
Дата
Msg-id 1254228899.11177.43.camel@jarahp.office.nic.cz
обсуждение исходный текст
Ответ на Re: lazy vacuum and AccessExclusiveLock  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-general
Hello,

thanks for comments. But what is a conclusion? Using manual vacuum is
considered as dangerous (with respect to locking) and the best is to
avoid using it? What does it mean "kick off autovacuum"? Only "cleaning
part" that needs lock will be omitted but dead tuples are freed, or
whole table must wait to next autovacuum run and hope that it will not
be kicked off once again?

Regards,
Jaromir

Alvaro Herrera píše v Pá 25. 09. 2009 v 18:41 -0400:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre@commandprompt.com> writes:
> > > An alternative solution would be to lower the vacuum delay settings before
> > > starting the truncating phase, but this doesn't work very well in autovacuum
> > > due to the autobalancing code (which can cause other processes to change our
> > > cost delay settings).  This case could be considered in the balancing code, but
> > > it is simpler this way.
> >
> > I don't think autovacuum has a problem --- if someone requests a
> > conflicting lock, autovac will get kicked off, no?  The OP's problem
> > comes from doing a manual vacuum.  Perhaps "don't do that" is a good
> > enough answer.
>
> Hah, that was part of the commit message, which predates autovacuum
> getting kicked out in case of conflicting locks IIRC.
>
> I think the process being described is unusual enough that a manual
> vacuum at just the right time is warranted ...
>
--
Jaromir Talir
technicky reditel / Chief Technical Officer
-------------------------------------------
CZ.NIC, z.s.p.o.  --    .cz domain registry
Americka 23, 120 00 Praha 2, Czech Republic
mailto:jaromir.talir@nic.cz  http://nic.cz/
sip:jaromir.talir@nic.cz tel:+420.222745107
mob:+420.739632712       fax:+420.222745112
-------------------------------------------

Вложения

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

Предыдущее
От: Sam Mason
Дата:
Сообщение: Re: query is taking longer time after a while
Следующее
От: Brian Modra
Дата:
Сообщение: Re: query is taking longer time after a while