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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [HACKERS] Clarification in pg10'spgupgrade.html step 10 (upgrading standby servers)
Дата
Msg-id 20170912235415.GT4628@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [HACKERS] Clarification in pg10'spgupgrade.html step 10 (upgrading standby servers)  (Andreas Joseph Krogh <andreas@visena.com>)
Ответы Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers)  (Andreas Joseph Krogh <andreas@visena.com>)
Re: [HACKERS] Clarification in pg10'spgupgrade.html step 10 (upgrading standby servers)  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Andreas,

* Andreas Joseph Krogh (andreas@visena.com) wrote:
> I have to ask; Why not run pg_upgrade on standby, after verifying that it's in
> sync with primary and promoting it to primary if necessary and then making it
> standby again after pg_upgrade is finished?

I don't think that we could be guaranteed that the catalog tables would
be the same on the replica as on the primary if they were actually
created by pg_upgrade.

The catalog tables *must* be identical between the primary and the
replica because they are updated subsequently through WAL replay, not
through SQL commands (which is how pg_upgrade creates them in the first
place).

Perhaps we could have some mode for pg_upgrade where it handles the
update to replicas (with the additional checks that I outlined and using
the methodology discussed for rsync --hard-links), but that would still
require solving the communicate-over-the-network problem between the
primary and the replicas, which is the hard part.  Whether it's an
independent utility or something built into pg_upgrade isn't really that
big of a distinction, though it doesn't seem to me like there'd be much
code reuse there.

Thanks!

Stephen

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Automatic testing of patches in commit fest
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: [HACKERS] Faster methods for getting SPI results