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

From Jan Wieck
Subject Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Date
Msg-id 4D91200D.4020005@Yahoo.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>)
Responses Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
List pgsql-bugs
On 3/28/2011 4:01 PM, Tom Lane 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.
>>    - 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.


Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

pgsql-bugs by date:

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