Re: lazy vacuum and AccessExclusiveLock

From: Jaromír Talíř <jaromir(dot)talir(at)nic(dot)cz>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: lazy vacuum and AccessExclusiveLock
Date: 2009-09-29 12:54:59
Message-ID: 1254228899.11177.43.camel@jarahp.office.nic.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)commandprompt(dot)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(dot)talir(at)nic(dot)cz http://nic.cz/
sip:jaromir(dot)talir(at)nic(dot)cz tel:+420.222745107
mob:+420.739632712 fax:+420.222745112
-------------------------------------------

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Brian Modra 2009-09-29 13:13:49 Re: query is taking longer time after a while
Previous Message Sam Mason 2009-09-29 12:54:58 Re: query is taking longer time after a while