Re: Summary of plans to avoid the annoyance of Freezing - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Summary of plans to avoid the annoyance of Freezing
Date
Msg-id CAMkU=1xpxEZVRBkGY_7fcAPAJJkez89uvhJmiLd1K3ycs-CcAQ@mail.gmail.com
Whole thread Raw
In response to Re: Summary of plans to avoid the annoyance of Freezing  (Greg Stark <stark@mit.edu>)
Responses Summary of plans to avoid the annoyance of Freezing  (martinwerfel12 <martinwerfel12@gmail.com>)
List pgsql-hackers
On Wed, Sep 9, 2015 at 6:03 AM, Greg Stark <stark@mit.edu> wrote:
On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund <andres@anarazel.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

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Multi-tenancy with RLS
Next
From: Michael Paquier
Date:
Subject: Re: Can extension build own SGML document?