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)
Re: [HACKERS] Clarification in pg10'spgupgrade.html step 10 (upgrading standby servers) |
Список | 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 по дате отправления: