Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CANP8+jJVfk+KVpEDYQ9AuMfutkwGmHOhtsy=aQaWRS7qeSa7HQ@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Freeze avoidance of very large table.  (Andres Freund <andres@anarazel.de>)
Re: Freeze avoidance of very large table.  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 1 October 2015 at 23:30, Josh Berkus <josh@agliodbs.com> wrote:
On 10/01/2015 07:43 AM, Robert Haas wrote:
> On Thu, Oct 1, 2015 at 9:44 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> I wonder how much it's worth renaming only the file extension while
>> there are many places where "visibility map" and "vm" are used,
>> for example, log messages, function names, variables, etc.
>
> I'd be inclined to keep calling it the visibility map (vm) even if it
> also contains freeze information.
>

-1 to rename.  Visibility Map is a perfectly good name.

The name can stay the same, but specifically the file extension should change.

This patch changes the layout of existing information:
* _vm stores one bit per page
* _$new stores two bits per page

The problem is we won't be able to tell the two formats apart, since they both are just lots of bits. So we won't be able to tell if the file is old format or new format, which could lead to loss of information that relates to visibility. If we think something is all-visible when it is not, this is effectively data corruption.

In light of lessons learned from multixactids, I think its important that we are able to tell the difference between an old format and a new format visibility map. 

My suggestion to do so was to call it "vfm", so we indicate that it is now a Visibility & Freeze Map

I don't care if we change the name, but I do care if we can't tell the difference between a failed upgrade, a normal upgrade and a server that has been upgraded multiple times. Alternate suggestions welcome.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Andres Freund
Date:
Subject: Re: Freeze avoidance of very large table.