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 | AANLkTimiCkmZ5NL=iPUG08TRAd-OJp_M1sR2SCm6c2BL@mail.gmail.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 Fri, Mar 25, 2011 at 11:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Maxim Boguk" <Maxim.Boguk@gmail.com> writes: >> In my case vacuum tried to truncate last 10-15GB from 100Gb relation, and >> each time (3) it was cost 10+ minutes of service downtime (because that >> table was completely locked). > >> Is =A0that correct behaviour? Are here any way to speedup that process o= r at >> least allow read-only queries during that time? > > Use autovacuum --- if there's something that wants to access the table, > autovac will get kicked off the lock. =A0(Of course, the table may never > get truncated then, but maybe you don't care.) I could see this turning out somewhat unhappily... If there's almost always something that wants to access the table, which would be hardly surprising, in view that the table is being updated with sufficient regularity that it's got 10GB+ of dead space at the end, then you're eventually going to *HAVE* to vacuum it. Transaction rollover, and what not. The piper will need to get paid, eventually :-(. So I don't think leaving it to autovacuum quite suffices, because eventually there's a 10 minute "glut", or more, that needs to get paid. --=20 http://linuxfinances.info/info/linuxdistributions.html
В списке pgsql-bugs по дате отправления: