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

From Tom Lane
Subject Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Date
Msg-id 28594.1301342493@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5946: Long exclusive lock taken by vacuum (not full)  (Christopher Browne <cbbrowne@gmail.com>)
Responses Re: BUG #5946: Long exclusive lock taken by vacuum (not full)  (Christopher Browne <cbbrowne@gmail.com>)
Re: BUG #5946: Long exclusive lock taken by vacuum (not full)  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-bugs
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.
>   - Commit & give up the lock for a bit if they do
>   - Go back and process more pages if they don't

Actually, we could simplify that even further.  Keep 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.  Truncate 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().  The really good thing about it is that
vacuum's work is never wasted.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5950: backend terminating after altering table
Next
From: Christopher Browne
Date:
Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)