| 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 |
| Message-ID: | 20180530180026.GB25072@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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?
--
Michael
| 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 ) |