Re: Summary of plans to avoid the annoyance of Freezing

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Summary of plans to avoid the annoyance of Freezing
Date: 2015-09-15 09:24:03
Message-ID: CAD21AoD5qPgdiK4Zem18zoat8s7v8nuWTvmQbEznOuj1ZiAPZQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 9, 2015 at 10:03 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> My vote is that we should try to get freeze maps into 9.6 - that seems
>> more realistic given that we have a patch right now. Yes, it might end
>> up being superflous churn, but it's rather localized. I think around
>> we've put off significant incremental improvements off with the promise
>> of more radical stuff too often.
>
> Superfluous churn in the code isn't too bad. But superfluous churn in
> data formats might be a bit more scary. Would we be able to handle
> pg_upgrade from a database with or without a freezemap? Would you have
> to upgrade once to add the freezemap then again to remove it?
>

Currently freeze map patch adds frozen bit to visibility map when
upgrading to 9.6.
The visibility map is not critical information, and is generated by VACUUM.
So we can drop it and create new visibility map by doing VACUUM, if
table size is not large.

Regards,

--
Masahiko Sawada

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message YUriy Zhuravlev 2015-09-15 09:51:24 Re: Move PinBuffer and UnpinBuffer to atomics
Previous Message David Rowley 2015-09-15 09:18:56 Re: [PROPOSAL] Covering + unique indexes.