Re: Eliminating PD_ALL_VISIBLE, take 2

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

In response to

Responses

Browse pgsql-hackers by date

  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