Re: behave of --create-slot option

2018-05-29 6:11 GMT+02:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:

> On 29 May 2018 at 11:51, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>