From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Eliminating PD_ALL_VISIBLE, take 2 |
Date: | 2013-05-30 08:32:58 |
Message-ID: | 51A70EBA.4030108@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-05-30 09:02:17 | Re: pg_dump with postgis extension dumps rules separately |
Previous Message | Joshua D. Drake | 2013-05-30 08:28:31 | Re: units in postgresql.conf comments |