Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
От | Christopher Browne |
---|---|
Тема | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |
Дата | |
Msg-id | AANLkTimB_F=KMHUnhFE196AQ0J4QYbaua3Kt4FLjDc9P@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Mon, Mar 28, 2011 at 4:01 PM, Tom Lane <tgl@sss.pgh.pa.us> 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. >> =A0 - Commit & give up the lock for a bit if they do >> =A0 - Go back and process more pages if they don't > > Actually, we could simplify that even further. =A0Keep 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. =A0Truncate 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(). =A0The really good thing about it is that > vacuum's work is never wasted. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, tom lane That mostly sounds excellent. One caveat is that this has the risk, for a busy table, of having it take nearly forever to get through the truncation of the empty space at the end. If the VACUUM falls out, under this logic, after truncating only a few pages, then there's the considerable cost of rummaging through the table, over and over, truncating only a few pages each time. Supposing we set it up to truncate 32 pages (assuming that to be the "safe" level), and there are 10 empty 1GB files at the end of the table, then it's potentially going to take tens of thousands of VACUUM requests to empty that whole chunk of space out. That seems close enough to "forever" for my purposes :-), assuming I'm understanding that correctly. I hope I'm wrong, and that there's potential here to get quite a bit more pages than that dropped out. --=20 http://linuxfinances.info/info/linuxdistributions.html
В списке pgsql-bugs по дате отправления: