Re: pgsql: Introduce replication slots.

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Introduce replication slots.
Date: 2014-02-04 05:19:28
Message-ID: CAB7nPqSdA_D1WVdTVO+qawO2_swyng9fCL0nqJStUp+YiOEUTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Sat, Feb 1, 2014 at 6:33 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Sat, Feb 1, 2014 at 6:09 PM, Andres Freund <andres(at)2ndquadrant(dot)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(at)postgresql(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2014-02-04 06:38:57 Re: Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)
Previous Message Noah Misch 2014-02-04 05:08:09 Re: Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)