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
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 |