Re: [HACKERS] Proposal for changes to recovery.conf API

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Proposal for changes to recovery.conf API
Дата
Msg-id 20161217213444.GD19805@momjian.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal for changes to recovery.conf API  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On Sat, Dec 17, 2016 at 02:52:41PM +0100, Magnus Hagander wrote:
>     The point is that the documentation about the recovery.conf changes in
>     Postgres are only interesting to people migrating to Postgres 10, i.e.
>     this is not quality documentation for someone going from Postgres 10 to
>     Postgres 11.
> 
> 
> 
> They will also be interesting to people going from 9.4 to 11, or from 9.3 to
> 12. Or from 9.5 to 13.
> 
> They only become uninteresting when we stop supporting 9.6 which is the last
> version that didn't have that functionality. 

No, they become uninteresting to anyone who has passed Postgres 10.  I
would argue they are still required to be around even after we stop
supporting Postgres 9.6 because we know everyone will not upgrade off of
supported releases once we stop supporting them.  This means we can
effectively never remove the information.

Right now if you migrate from Postgres 8.0 to Postgres 9.6, all the
information you need is in the 9.6 documentation.  If you were to remove
migration details from 8.4 to 9.0 they would have to look at the 9.0
docs to get a full picture of how to migrate.

Again, I am fine putting this as a subsection of the release notes, but
let's not pretend it is some extra section we can remove in five years.

--  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-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] CREATE OR REPLACE VIEW bug
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Speedup twophase transactions