Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
От | Jan Wieck |
---|---|
Тема | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |
Дата | |
Msg-id | 4D91200D.4020005@Yahoo.com обсуждение исходный текст |
Ответ на | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
|
Список | 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 по дате отправления: