On 3/28/2011 4:01 PM, Tom Lane wrote:
> Christopher Browne<cbbrowne(at)gmail(dot)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.
I somehow fail to see how this complete reversal of who does what and
affecting code in entirely different parts of the system will qualify
for patching back releases.
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2011-03-29 00:07:18|
|Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |
|Previous:||From: Christopher Browne||Date: 2011-03-28 20:21:50|
|Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)|