On Tue, Mar 26, 2024 at 8:27 AM Euler Taveira <euler@eulerto.com> wrote:
>
> On Mon, Mar 25, 2024, at 11:33 PM, Amit Kapila wrote:
>
> On Mon, Mar 25, 2024 at 5:25 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> >
> > I have committed your version v33. I did another pass over the
> > identifier and literal quoting. I added quoting for replication slot
> > names, for example, even though they can only contain a restricted set
> > of characters, but it felt better to be defensive there.
> >
> > I'm happy to entertain follow-up patches on some of the details like
> > option naming that were still being discussed. I just wanted to get the
> > main functionality in in good time. We can fine-tune the rest over the
> > next few weeks.
> >
>
> I was looking at prior discussions on this topic to see if there are
> any other open design points apart from this and noticed that the
> points raised/discussed in the email [1] are also not addressed. IIRC,
> the key point we discussed was that after promotion, the existing
> replication objects should be removed (either optionally or always),
> otherwise, it can lead to a new subscriber not being able to restart
> or getting some unwarranted data.
>
>
> See setup_subscriber.
>
> /*
> * Since the publication was created before the consistent LSN, it is
> * available on the subscriber when the physical replica is promoted.
> * Remove publications from the subscriber because it has no use.
> */
> drop_publication(conn, &dbinfo[I]);
>
This only drops the publications created by this tool, not the
pre-existing ones that we discussed in the link provided.
--
With Regards,
Amit Kapila.