Re: pg_upgrade and logical replication
От | Michael Paquier |
---|---|
Тема | Re: pg_upgrade and logical replication |
Дата | |
Msg-id | ZUbaFX0JTzUo-bux@paquier.xyz обсуждение исходный текст |
Ответ на | Re: pg_upgrade and logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Thu, Nov 02, 2023 at 05:00:55PM +0530, Amit Kapila wrote: > I think it is important for users to know how they upgrade their > multi-node setup. Say a two-node setup where replication is working > both ways (aka each node has both publications and subscriptions), > similarly, how to upgrade, if there are multiple nodes involved? +1. My next remarks also apply to the thread where publishers are handled in upgrades, but I'd like to think that at the end of the release cycle it would be nice to have the basic features in, with also a set of regression tests for logical upgrade scenarios that we'd expect to work. Two "basic" ones coming into mind: - Cascading logical setup, with one node in the middle having both publisher(s) and subscriber(s). - Two-way replication, with two nodes. > One more thing I was thinking about this patch was that here unlike > the publication's slot information, we can't ensure with origin's > remote_lsn that all the WAL is received and applied before allowing > the upgrade. I can't think of any problem at the moment due to this > but still a point worth giving a thought. Yeah, that may be an itchy point, which is also related to my concerns on trying to allow more syncstates than ready when beginning the upgrade, which is at least a point we are sure that a relation was up to date, up to a certain point. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: