From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christopher Browne <cbbrowne(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |
Date: | 2011-03-28 23:55:57 |
Message-ID: | 4D91200D.4020005@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-03-29 00:07:18 | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |
Previous Message | Christopher Browne | 2011-03-28 20:21:50 | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |