From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_upgrade and logical replication |
Date: | 2023-09-04 06:44:54 |
Message-ID: | ZPV85hix0dgcXl/j@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 04, 2023 at 11:51:14AM +0530, Amit Kapila wrote:
> +1 for doing it via function (something like
> binary_upgrade_create_sub_rel_state). We already have the internal
> function AddSubscriptionRelState() that can do the core work.
It is one of these patches that I have let aside for too long, and it
solves a use-case of its own. I think that I could hack that pretty
quickly given that Julien has done a bunch of the ground work. Would
you agree with that?
> Like the publisher-side upgrade patch [1], I think we should allow
> upgrading subscriptions by default instead with some flag like
> --preserve-subscription-state. If required, we can introduce --exclude
> option for upgrade. Having it just for pg_dump sounds reasonable to
> me.
>
> [1] - https://www.postgresql.org/message-id/TYAPR01MB58664C81887B3AF2EB6B16E3F5939%40TYAPR01MB5866.jpnprd01.prod.outlook.com
In the interface of the publisher for pg_upgrade agreed on and set in
stone? I certainly agree to have a consistent upgrade experience for
the two sides of logical replication, publications and subscriptions.
Also, I'd rather have a filtering option at the same time as the
upgrade option to give more control to users from the start.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-09-04 06:49:35 | Re: pg_upgrade and logical replication |
Previous Message | Amit Kapila | 2023-09-04 06:26:14 | Re: pg_upgrade and logical replication |