From: | martinwerfel12 <martinwerfel12(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Summary of plans to avoid the annoyance of Freezing |
Date: | 2018-07-24 07:52:06 |
Message-ID: | 1532418726167-0.post@n3.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* 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 superfluous 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 scarier. Would we be able to handle
pg_upgrade from a database with or without a freeze map? Would you have?
To upgrade once to add the freeze map 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,
Martin
-----
Kamagra
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Travers | 2018-07-24 07:54:38 | Documenting that queries can be run over replication protocol |
Previous Message | Masahiko Sawada | 2018-07-24 07:47:41 | Re: [HACKERS] Restricting maximum keep segments by repslots |