On Wed, May 22, 2024 at 8:00 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, May 22, 2024 at 9:52 AM Robert Haas <robertmh...@gmail.com> wrote: > > 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? > >
This tool's intended purpose is to speed up the creation of a subscriber node and for that one won't need the subscriptions already present on the existing primary/publisher node from which the new subscriber node is going to get the data. Additionally, the ERRORs shown by Shlok will occur even during the command (performed by pg_createsubscriber) which will probably be confusing. > > Maybe it is unreasonable to say that, but it seems to me we should at > > least talk about that. > > As another option, maybe we could disable subscriptions, so that > nothing happens when the server is first started, and then the user > could decide after that what they want to do. > Yeah, this would be worth considering. Note that even if the user wants to retain such pre-existing subscriptions and enable them, they need more steps than just to enable these to avoid duplicate data issues or ERRORs as shown in Shlok's test. So, we have the following options: (a) by default drop the pre-existing subscriptions, (b) by default disable the pre-existing subscriptions, and add a Note in the docs that users can take necessary actions to enable or drop them. Now, we can even think of providing a switch to retain the pre-existing subscriptions or publications as the user may have some use case where it can be helpful for her. For example, retaining publications can help in creating a bi-directional setup. -- With Regards, Amit Kapila.
