lazy_truncate_heap()
От | Simon Riggs |
---|---|
Тема | lazy_truncate_heap() |
Дата | |
Msg-id | 1230747694.4032.72.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответы |
Re: lazy_truncate_heap()
Re: lazy_truncate_heap() |
Список | pgsql-hackers |
While watching WAL records float by I noticed some AccessExclusiveLocks occurring unnecessarily during VACUUMs. This is caused by lines 186-189 in lazy_vacuum_rel(), vacuumlazy.c possibly_freeable = vacrelstats->rel_pages - vacrelstats->nonempty_pages; if (possibly_freeable >= REL_TRUNCATE_MINIMUM|| possibly_freeable >= vacrelstats->rel_pages / REL_TRUNCATE_FRACTION) lazy_truncate_heap(onerel,vacrelstats); If you look closely you'll see that if rel_pages is small then we will attempt to truncate the heap even if possibly_freeable == 0. While looking at this some more, I notice there is another bug. When VACUUM has nothing at all to do, then it appears that vacrelstats->nonempty_pages is zero, so that possibly_freeable is always set to vacrelstats->rel_pages. vacrelstats->nonempty_pages doesn't appear to be used anywhere else, so nobody notices it is wrongly set. Both of these bugs are minor, but the effect of either/both of them is to cause more AccessExclusiveLocks than we might expect. For Hot Standby this means that many VACUUMs take AccessExclusiveLocks on relations, which would potentially lead to having queries cancelled for no reason at all. Does anybody think any of the above is intentional? Can I fix? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: