Re: pgsql: Introduce replication slots. - Mailing list pgsql-committers

From Michael Paquier
Subject Re: pgsql: Introduce replication slots.
Date
Msg-id CAB7nPqSdA_D1WVdTVO+qawO2_swyng9fCL0nqJStUp+YiOEUTw@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Introduce replication slots.  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: pgsql: Introduce replication slots.  (Thom Brown <thom@linux.com>)
List pgsql-committers
On Sat, Feb 1, 2014 at 6:33 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Sat, Feb 1, 2014 at 6:09 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> On 2014-02-01 16:47:47 +0900, Fujii Masao wrote:
>>> On Sat, Feb 1, 2014 at 12:50 PM, Robert Haas <rhaas@postgresql.org> wrote:
>>> > Introduce replication slots.
>>> >
>>> > Replication slots are a crash-safe data structure which can be created
>>> > on either a master or a standby to prevent premature removal of
>>> > write-ahead log segments needed by a standby, as well as (with
>>> > hot_standby_feedback=on) pruning of tuples whose removal would cause
>>> > replication conflicts.  Slots have some advantages over existing
>>> > techniques, as explained in the documentation.
>>> >
>>> > In a few places, we refer to the type of replication slots introduced
>>> > by this patch as "physical" slots, because forthcoming patches for
>>> > logical decoding will also have slots, but with somewhat different
>>> > properties.
>>>
>>> This patch changed basebackup.c so that it skips pg_replslot. It's OK
>>> to skip all files in that directory, but an empty pg_replslot must be
>>> included in the backup. Otherwise we cannot start PostgreSQL from
>>> the backup taken via pg_basebackup. Attached patch fixes this problem.
>>
>> That's a pretty fair point. Not sure how that could escape my
>> notice. The patch does look sane to me.
>>
>> I wonder if we additionally should add code to recreate pg_replslot on
>> startup, similar to pg_xlog?
>
> Similar to pg_xlog/archive_status, not pg_xlog? That might be an option.
> But I'm not inclined to do that for now. The fact that the essential
> directory like
> pg_replslot doesn't exist indicates the symptom of something strange. And,
> changing that way might prevent us from detecting such symptom.
To facilitate the user's life, I would be more inclined to do the following:
1) Have pg_replslot created if it does not exist in the base backup
such as users are not surprised that there old scripts do not work
anymore with 9.4
2) Add a new option in BASE_BACKUP (and pg_basebackup as well) to
stream pg_replslot data at will, because I see use cases for both
keeping those files in a base backup as well as removing them.
Regards,
--
Michael


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Improve connection-failure error handling in contrib/postgres_fd
Next
From: Jeff Davis
Date:
Subject: Re: pgsql: arrays: tighten checks for multi-dimensional input