Re: Summary of plans to avoid the annoyance of Freezing
| От | Jeff Janes |
|---|---|
| Тема | Re: Summary of plans to avoid the annoyance of Freezing |
| Дата | |
| Msg-id | CAMkU=1xpxEZVRBkGY_7fcAPAJJkez89uvhJmiLd1K3ycs-CcAQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Summary of plans to avoid the annoyance of Freezing (Greg Stark <stark@mit.edu>) |
| Ответы |
Summary of plans to avoid the annoyance of Freezing
|
| Список | 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 по дате отправления: