Re: pg_upgrade and logical replication
От | Julien Rouhaud |
---|---|
Тема | Re: pg_upgrade and logical replication |
Дата | |
Msg-id | 20230309083456.xpjcsuycyn7d2yvr@jrouhaud обсуждение исходный текст |
Ответ на | Re: pg_upgrade and logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: pg_upgrade and logical replication
|
Список | pgsql-hackers |
Hi, On Thu, Mar 09, 2023 at 12:05:36PM +0530, Amit Kapila wrote: > On Wed, Mar 8, 2023 at 12:26 PM Julien Rouhaud <rjuju123@gmail.com> wrote: > > > > Is there something that can be done for pg16? I was thinking that having a > > fix for the normal and easy case could be acceptable: only allowing > > pg_upgrade to optionally, and not by default, preserve the subscription > > relations IFF all subscriptions only have tables in ready state. Different > > states should be transient, and it's easy to check as a user beforehand and > > also easy to check during pg_upgrade, so it seems like an acceptable > > limitations (which I personally see as a good sanity check, but YMMV). It > > could be lifted in later releases if wanted anyway. > > > > It's unclear to me whether this limited scope would also require to > > preserve the replication origins, but having looked at the code I don't > > think it would be much of a problem as the local LSN doesn't have to be > > preserved. > > > > I think we need to preserve replication origins as they help us to > determine the WAL location from where to start the streaming after the > upgrade. If we don't preserve those then from which location will the > subscriber start streaming? It would start from the slot's information on the publisher side, but I guess there's no guarantee that this will be accurate in all cases. > We don't want to replicate the WAL which > has already been sent. Yeah I agree. I added support to also preserve the subscription's replication origin information, a new --preserve-subscription-state (better naming welcome) documented option for pg_upgrade to optionally ask for this new mode, and a similar (but undocumented) option for pg_dump that only works with --binary-upgrade and added a check in pg_upgrade that all relations are in 'r' (ready) mode. Patch v2 attached.
Вложения
В списке pgsql-hackers по дате отправления: