Re: State of pg_createsubscriber - Mailing list pgsql-hackers

From Robert Haas
Subject Re: State of pg_createsubscriber
Date
Msg-id CA+TgmoZR=m7pzzMj7_8JrrT7cq9hK8VGH68SytE=z9FeriS22A@mail.gmail.com
Whole thread Raw
In response to Re: State of pg_createsubscriber  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: State of pg_createsubscriber
List pgsql-hackers
On Wed, May 22, 2024 at 7:42 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> So, what shall we do about such cases?  I think by default we can
> remove all pre-existing subscriptions and publications on the promoted
> standby or instead we can remove them based on some switch. If we want
> to go with this idea then we might need to distinguish the between
> pre-existing subscriptions and the ones created by this tool.
>
> The other case I remember adding an option in this tool was to avoid
> specifying slots, pubs, etc. for each database. See [1]. We can
> probably leave if the same is not important but we never reached the
> conclusion of same.

Another option that we should at least consider is "do nothing". In a
case like the one Shlok describes, how are we supposed to know what
the right thing to do is? Is it unreasonable to say that if the user
doesn't want those publications or subscriptions to exist, the user
should drop them?

Maybe it is unreasonable to say that, but it seems to me we should at
least talk about that.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: zlib detection in Meson on Windows broken?
Next
From: Dmitry Dolgov
Date:
Subject: Re: Schema variables - new implementation for Postgres 15