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
>
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 |