Re: behave of --create-slot option - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: behave of --create-slot option
Date
Msg-id CAFj8pRAqx8hs9xVgsfEXksxoWEN9pazR9EfCWziKDm4XOZae6Q@mail.gmail.com
Whole thread Raw
In response to Re: behave of --create-slot option  (Euler Taveira <euler@timbira.com.br>)
Responses Re: behave of --create-slot option  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers


2018-05-29 16:53 GMT+02:00 Euler Taveira <euler@timbira.com.br>:
2018-05-29 1:31 GMT-03:00 Pavel Stehule <pavel.stehule@gmail.com>:
> 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.
>
If pg_basebackup failed for some other reason *after* the replication
slot was created (say, permission problem) then we should try to
cleanup the old slot. That should be the behavior if we want to try to
be idempotent ("try" because if we have a network problem it won't be
possible to remove the replication slot).

It has sense for me

Pavel



--
   Euler Taveira                                   Timbira -
http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: "column i.indnkeyatts does not exist" in pg_upgrade from 11devto 11b1
Next
From: Masahiko Sawada
Date:
Subject: Re: Few comments on commit 857f9c36 (skip full index scans )