2018-05-29 6:11 GMT+02:00 Craig Ringer <cr...@2ndquadrant.com>: > On 29 May 2018 at 11:51, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > >> >> 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. Regards Pavel > > > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
