Re: 9.6 -> 10.0
От | Bruce Momjian |
---|---|
Тема | Re: 9.6 -> 10.0 |
Дата | |
Msg-id | 20160510212124.GC22757@momjian.us обсуждение исходный текст |
Ответ на | Re: 9.6 -> 10.0 (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: 9.6 -> 10.0
|
Список | pgsql-advocacy |
On Mon, May 9, 2016 at 06:42:40PM +0200, Magnus Hagander wrote: > That's exactly my thinking. If it's going to be *feature based* there is a > fairly significant risk of this happening. > > I think the only reason to not do a 10.0 is if we want to stick to the "we > switch when we break backwards compatibility". But that also means that if we > succeed in not breaking backwards compatibility in a bad way (say we solve the > problem of transparent page format upgrading, or just the logical replication > based upgrading or whatever), then we never bump. Which *also* doesn't work > very well. If we are going to focus on update method _change_ rather than just upgrade _breakage_, the inclusion of pg_logical in Postgres core would be a reason to go to 10.0 because it allows zero-downtime upgrades. I think this would be larger upgrade-wise than anything in 9.6. Currently users are using high-overhead trigger-based replication to achieve zero-downtime upgrades, and using streaming replication with pg_logical would be a game-changer. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-advocacy по дате отправления: