Re: Summary of plans to avoid the annoyance of Freezing

From: Jeff Janes <jeff(dot)janes(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>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
Subject: Re: Summary of plans to avoid the annoyance of Freezing
Date: 2015-09-15 20:19:04
Message-ID: CAMkU=1xpxEZVRBkGY_7fcAPAJJkez89uvhJmiLd1K3ycs-CcAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 9, 2015 at 6:03 AM, 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?
>

Surely we wouldn't introduce and remove freeze-maps between minor
versions. So either it is a new major version, in which case you would be
doing the upgrade anyway, or they would be added and then removed again all
within one development cycle; and running unreleased code always has
on-disk incompatibility churn. Or am I missing your point here?

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-09-15 20:29:41 Re: pgsql: RLS refactoring
Previous Message Stephen Frost 2015-09-15 20:00:53 Re: Multi-tenancy with RLS