On 2019-09-24 16:31, Jeff Janes wrote: > I recently had to cut loose (pg_drop_replication_slot) a logical replica > that couldn't keep up and so was threatening to bring down the master. > > In mopping up on the replica side, I couldn't just drop the > subscription, because it couldn't drop the nonexistent slot on the > master and so refused to work. So I had to do a silly little dance > where I first disable the subscription, then ALTER SUBSCRIPTION ... SET > (slot_name = NONE), then drop it. > > Wanting to clean up after itself is admirable, but if there is nothing > to clean up, why should that be an error condition?
The alternatives seem quite error prone to me. Better be explicit.
If you can connect to the master, and see that the slot already fails to exist, what is error prone about that?
If someone goes to the effort of setting up a different master, configures it to receive replica connections, and alters the subscription CONNECTION parameter on the replica to point to that poisoned master, will an error on the DROP SUBSCRIPTION really force them to see the error of their ways, or will they just succeed at explicitly doing the silly dance and finalize the process of shooting themselves in the foot via a roundabout mechanism? (And at the point the CONNECTION is changed, he is in the same boat even if he doesn't try to drop the sub--either way the master has a dangling slot). I'm in favor of protecting a fool from his foolishness, except when it is annoying to the rest of us (Well, annoying to me, I guess. I don't know yet about the rest of us).
