From: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade and publication/subscription problem |
Date: | 2021-11-27 12:44:36 |
Message-ID: | CAB-JLwZDr2-L6iNYe-KDzEc9n=G8fTGT44n=cch3DC1KzUh5cg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> I think we don't want to make assumptions about the remote end being
> the same after the upgrade and we let users reactivate the
> subscriptions in a suitable way. See [1] (Start reading from "..When
> dumping logical replication subscriptions..") In your case, if you
> wouldn't have allowed new tables in the publication then a simple
> Alter Subscription <sub_name> Refresh Publication with (copy_data =
> false) would have served the purpose.
I understand that this is not related with version 14, pg_upgrade would do
the same steps on previous versions too.
Additionally it would be interesting to document that pg_upgrade does not
upgrade completely if the server is a subscriber of logical replication, so
it´ll have pre and post steps to do if the server has this kind of
replication.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-11-27 13:55:29 | Re: Windows build warnings |
Previous Message | Amit Kapila | 2021-11-27 11:51:53 | Re: pg_upgrade and publication/subscription problem |