Skip site navigation (1) Skip section navigation (2)

Re: lazy vacuum sleeps with exclusive lock on table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lazy vacuum sleeps with exclusive lock on table
Date: 2007-06-29 00:34:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> What I'm requesting here is that the sleep in count_nondeletable_pages()
> be removed and that change backpatched to 8.2 and 8.1.

Are you sure that that is, and always will be, the only sleep in that
part of the code path?

Seems like it might be better to adjust the cost_delay parameters after
we acquire exclusive lock.  I'm not sure dialing them all the way back
to zero is a good idea, but certainly we could make them more

>> Seems like VACUUM shouldn't try just once to get the lock.

> We don't know how many pages we can truncate until after we have
> acquired the exclusive lock and examined the pages in question, scanning
> backwards from the end of the table.

We could estimate this during the forward scan.  The backward scan is
still necessary to see if anyone has inserted tuples after we looked at
a page, but certainly a page that VACUUM failed to empty will still be
nonempty, so we can determine an upper bound on how much might be

However, that's an orthogonal concern and should probably be discussed

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2007-06-29 00:50:36
Subject: Re: AutoVacuum Behaviour Question
Previous:From: ITAGAKI TakahiroDate: 2007-06-29 00:29:09
Subject: Re: lazy vacuum sleeps with exclusive lock on table

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group