On Fri, May 31, 2013 at 1:44 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May 31, 2013 at 10:28:12AM -0700, Josh Berkus wrote:
>> >> Isn't the visibility map already required for proper return results as
>> >> we use it for index-only scans. I think the optimization-only ship has
>> >> sailed.
>> >
>> > At the moment we can remove it without causing corruption. If we were to
>> > use it for freezing we couldn't anymore. So there's a difference - how
>> > big it is I am not sure.
>>
>> Depends on your definition of corruption, really.
>>
>> But yes, right now, the vismap can lose bits without causing any
>> corruption, and making all-frozen depend on it would eliminate that.
>
> Roberts statement was:
>
>> Loss or corruption of a single visibility map page means possible loss
>> of half a gigabyte of data.
>
> Certainly unidentified corruption of a visibility map page could easily
> cause incorrect results. So, technically, _adding_ bits would cause
> corruption.
Adding bits could cause tuples that ought to be invisible to be
treated as visible. Currently, removing bits is harmless (except to
performance), but if we used the VM bit to indicate whether the page
was frozen in lieu of actually freezing it, a cleared bit would
potentially cause vacuum to nuke everything on that page.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company