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

From Euler Taveira
Subject Re: behave of --create-slot option
Date
Msg-id CAHE3wghxF6hEsV-Fmb_q7HLUFJZqxtZU=8zhu-UMwGgW_dYETQ@mail.gmail.com
Whole thread Raw
In response to behave of --create-slot option  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
2018-05-28 16:41 GMT-03:00 Pavel Stehule <pavel.stehule@gmail.com>:
> I am writing a article about PostgreSQL 11 features. Now I am looking on new
> option --create-slot option of pg_basebackup command.
>
> I don't understand to use case for this option, because It fails when
> requested slot already exists. I cannot to imagine use case for this. If I
> write some scripts, then I prefer the behave like "create if doesn't exist
> or do nothing".
>
In prior versions, you should create a slot (via SQL function or
streaming replication protocol) *before* run pg_basebackup. In 11, use
--create-slot option and you don't need an extra step (of course, you
should drop that slot after the end of backup -- if that is not a new
standby. It also does not make sense to use _persistent_ replication
slots for backup because you are probably archiving WAL). IMHO the use
case is new standbys that will use replication slots.

> Any repeated running of script with this option should to fail. Is it
> required? Why?
>
As I said, you should have an extra step to drop that slot (even
before 11). There is no "create replication slots if not exists". If
you are repeatedly running a script, why don't you let pg_basebackup
use temporary replication slots?


-- 
   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: adding tab completions
Next
From: Craig Ringer
Date:
Subject: Re: behave of --create-slot option