From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Including replication slot data in base backups |
Date: | 2014-04-14 23:11:05 |
Message-ID: | CAB7nPqRV=69YsN7WKks=Rkf9iTbHO5JvSJd00x83cNawOHLDjw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 15, 2014 at 1:55 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Apr 14, 2014 at 9:26 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> This makes me think that it's safer to just remove replication slot files
>> at the beginning of the recovery when both backup_label and recovery.conf
>> exist.
>
> Well, we could do that, but that would preempt anyone who *does* want
> to keep those replication slots around. I'm not sure that's a good
> idea, either.
Same here, I still see cases where people might want to keep the
replication slot information around, particularly if they take an
atomic snapshot of PGDATA, which is something that some of our users
do. Enforcing removal of such files when recovery begins would only
bring less flexibility to the way recovery can be done.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-04-14 23:17:29 | Re: Excessive WAL generation and related performance issue |
Previous Message | Jim Nasby | 2014-04-14 23:04:37 | Re: Excessive WAL generation and related performance issue |