Re: behave of --create-slot option

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Euler Taveira <euler(at)timbira(dot)com(dot)br>, 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-30 18:00:26
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, May 29, 2018 at 09:21:00PM +0200, Pavel Stehule wrote:
> 2018-05-29 16:53 GMT+02:00 Euler Taveira <euler(at)timbira(dot)com(dot)br>:
>> 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

Hm. There could be an argument for improving the user experience here
so as some cleanup is at least attempted except if --no-clean is defined
by the caller when --create-slot is used. Do we want an open item for
this issue?

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Adrien Nayrat 2018-05-30 18:44:32 New GUC to sample log queries
Previous Message Teodor Sigaev 2018-05-30 16:46:58 Re: Few comments on commit 857f9c36 (skip full index scans )