Re: Eliminating PD_ALL_VISIBLE, take 2
От | Heikki Linnakangas |
---|---|
Тема | Re: Eliminating PD_ALL_VISIBLE, take 2 |
Дата | |
Msg-id | 51A70EBA.4030108@vmware.com обсуждение исходный текст |
Ответ на | Re: Eliminating PD_ALL_VISIBLE, take 2 (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Eliminating PD_ALL_VISIBLE, take 2
|
Список | pgsql-hackers |
On 30.05.2013 11:26, Heikki Linnakangas wrote: > On 30.05.2013 06:54, Jeff Davis wrote: >> Continuation of: >> >> http://www.postgresql.org/message-id/1353551097.11440.128.camel@sussancws0025 >> >> >> Rebased patch attached; no other changes. > >> @@ -675,6 +675,16 @@ lazy_scan_heap(Relation onerel, LVRelStats >> *vacrelstats, >> } >> >> /* >> + * If this page is left over from an upgraded system, it may have a >> + * PD_ALL_VISIBLE bit set (which is deprecated). If so, clear it. >> + */ >> + if (PageIsAllVisible(page)) >> + { >> + PageClearAllVisible(page); >> + MarkBufferDirty(buf); >> + } >> + >> + /* >> * Prune all HOT-update chains in this page. >> * >> * We count tuples removed by the pruning step as removed by VACUUM. > > That could cause a torn page and checksum failure if checksums are > enabled. Come to think of it, even without the torn page & checksum issue, do we really want to actively clear the all-visible flags after upgrade? For tables that haven't been changed, and thus have the all-visible bits set, that amounts to a complete rewrite on the first vacuum after upgrade. That's expensive. - Heikki
В списке pgsql-hackers по дате отправления: