I understand so slot should be unique. But same result (unique rep slot) can be done, if it does nothing when slot exists already. This behave is not idempotent.
Maybe I am search problem, where it is not. Just, when I see some "create object" option, I expect any way, how I can enforce "--if-exists", because it was necessary in major cases.
If the slot already exists, don't you expect it to be in use for an existing replica?
the slot name is unique, so I don't expect it - when I use some name from script
I guess what you seem to want is to be able to delete the replica then re-clone it and use the same slot?
maybe. Now, it looks "asymmetric"
Generally I'd expect you to delete the slot when you remove the replica. Really what this says to me is that we should have a way to delete the upstream slot when we promote or decommission a physical replica.
When I think about this option and designed behave, I am inclined to think so it can be hard to use, and better create slot outside, and outside drop slot too.
I hope so I understand to motivation for this option - but I see issues:
1. pg_basebackup can fail from some other reasons, but there is not special status for this issue.
2. when I use this option in any script, then I should to remove possibly exists slot before, to minimize risk of fail of this command.
I understand, current behave can be wanted like protection against unwanted running some deployment script. But can be problematic too, when pg_basebackup or or some other fails from unexpected reasons.
