Re: BUG #5946: Long exclusive lock taken by vacuum (not full) - Mailing list pgsql-bugs

From Christopher Browne
Subject Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Date
Msg-id AANLkTimB_F=KMHUnhFE196AQ0J4QYbaua3Kt4FLjDc9P@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5946: Long exclusive lock taken by vacuum (not full)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mon, Mar 28, 2011 at 4:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Christopher Browne <cbbrowne@gmail.com> writes:
>> - Grab timestamp
>> - Grab exclusive lock
>> - Process [Some number of pages]
>> - Check time.
>> - If [# of ms] have passed then check to see if anyone else has a lock
>> O/S on the table.
>> =A0 - Commit & give up the lock for a bit if they do
>> =A0 - Go back and process more pages if they don't
>
> Actually, we could simplify that even further. =A0Keep the code exactly
> as-is, but every small-number-of-pages, check to see if someone is
> waiting on a conflicting lock, and if so, fall out of the page checking
> loop. =A0Truncate away however many pages we know at that time are safe,
> and end the vacuum normally.
>
> We'd have to rejigger the stuff in the lock manager that tries to boot
> autovacuum off the lock forcibly, but with a bit of luck that would get
> less crocky not more so.
>
> This wouldn't really have any parameters that require tuning, I think,
> and the max delay till the lock is released is not too much more than
> the time needed for ftruncate(). =A0The really good thing about it is that
> vacuum's work is never wasted.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, tom lane

That mostly sounds excellent.

One caveat is that this has the risk, for a busy table, of having it
take nearly forever to get through the truncation of the empty space
at the end.

If the VACUUM falls out, under this logic, after truncating only a few
pages, then there's the considerable cost of rummaging through the
table, over and over, truncating only a few pages each time.

Supposing we set it up to truncate 32 pages (assuming that to be the
"safe" level), and there are 10 empty 1GB files at the end of the
table, then it's potentially going to take tens of thousands of VACUUM
requests to empty that whole chunk of space out.  That seems close
enough to "forever" for my purposes :-), assuming I'm understanding
that correctly.

I hope I'm wrong, and that there's potential here to get quite a bit
more pages than that dropped out.
--=20
http://linuxfinances.info/info/linuxdistributions.html

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Next
From: "Rob Grant"
Date:
Subject: BUG #5955: One-click installer does not escape password