Re: Eliminating PD_ALL_VISIBLE, take 2 - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Eliminating PD_ALL_VISIBLE, take 2
Date
Msg-id 51A70EBA.4030108@vmware.com
Whole thread Raw
In response to Re: Eliminating PD_ALL_VISIBLE, take 2  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Eliminating PD_ALL_VISIBLE, take 2
List 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 by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: units in postgresql.conf comments
Next
From: Dimitri Fontaine
Date:
Subject: Re: pg_dump with postgis extension dumps rules separately