| 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: | Whole Thread | Raw Message | 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 |