Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers)
Дата
Msg-id CA+TgmoZ=nAuNGtc8UwxmG8Ooyni5VHU=WniMXLjS6n3um23ohg@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standbyservers)  (Andreas Joseph Krogh <andreas@visena.com>)
Ответы Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers)  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Fri, Jul 28, 2017 at 10:35 AM, Andreas Joseph Krogh
<andreas@visena.com> wrote:
> I'm reading https://www.postgresql.org/docs/10/static/pgupgrade.html to try
> to understand how to upgrade standby-servers using pg_upgrade with pg10.
>
> The text in step 10 sais:
> "You will not be running pg_upgrade on the standby servers, but rather
> rsync", which to me sounds like rsync, in step 10-f, should be issued on the
> standy servers. Is this the case? If so I don't understand how the standby's
> data is upgraded and what "remote_dir" is. If rsync is supposed to be issued
> on the primary then I think it should be explicitly mentioned, and step 10-f
> should provide a clarer example with more detailed values for the
> directory-structures involved.
>
> I really think section 10 needs improvement as I'm certainly not comfortable
> upgrading standbys following the existing procedure.

Yeah, I don't understand it either, and I have never been convinced
that there's any safe way to do it other than recloning the standbys
from the upgraded master.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Mengxing Liu"
Дата:
Сообщение: [HACKERS] [GOSC' 17][Performance report] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Transactions involving multiple postgres foreign servers