Re: behave of --create-slot option

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Euler Taveira <euler(at)timbira(dot)com(dot)br>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: behave of --create-slot option
Date: 2018-05-29 19:21:00
Message-ID: CAFj8pRAqx8hs9xVgsfEXksxoWEN9pazR9EfCWziKDm4XOZae6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2018-05-29 16:53 GMT+02:00 Euler Taveira <euler(at)timbira(dot)com(dot)br>:

> 2018-05-29 1:31 GMT-03:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2018-05-29 20:05:51 Re: Few comments on commit 857f9c36 (skip full index scans )
Previous Message Justin Pryzby 2018-05-29 19:08:49 Re: "column i.indnkeyatts does not exist" in pg_upgrade from 11dev to 11b1