On Tuesday, March 11, 2025, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Wed, Mar 12, 2025 at 9:43 AM David G. Johnston > <david.g.johns...@gmail.com> wrote: > > > > I’m honestly question how much value this provides - no improvement here > seems like a viable choice. Let them issue the drop commands they desire > manually. This doesn’t feel like something one should/would automate. > > > > There is a good chance of mistakenly dropping the required objects > manually after the subscriber is converted. One can mistakenly drop > the required publication unless they have some strict rule to do it > immediately after the tool has converted standby to subscriber. If you are referring to “step 6”, that bypasses this requirement because pg_createsubscriber created it, knows the exact name, and it is well defined why that specific publication should be removed. > Providing the commands via file is a way, but as a user, I would > prefer to get the things done automatically via a tool instead of me > doing it afterward unless there is no other way.. > > Given that the fallback position is to restore the physical standby and do the transformation again I suppose it isn’t too bad if we or the user messes up a run. But you can still get the tool to basically do it for you automatically by just blindly sending the through psql. The people who want the safety net have no option. I suspect the percentage of DBAs that would appreciate the option would be meaningful. After all, we felt it necessary to add a —dry-run option. David J.
