Re: Copy function for logical replication slots

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Copy function for logical replication slots
Date: 2018-06-28 06:47:27
Message-ID: 20180628064727.GL11054@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 28, 2018 at 03:34:00PM +0900, Masahiko Sawada wrote:
> On Thu, Jun 28, 2018 at 12:29 PM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> Hm. Shouldn't the original slot copied be owned by the process doing
>> the copy with ReplicationSlotAcquire?
>
> Right, it should do and release it before creating new one.

Yes, or MyReplicationSlot would not like that.

>> There could be some cases where
>> copying a physical slot also makes sense.
>
> I've thought that but I didn't find concrete use case. That's why I
> started with only logical slot.

Let's imagine the case of a single base backup which is associated to a
given replication slot, and that this backup is then used to spawn
multiple standbys where each one of them needs a separate slot to
consume changes at their pace. If you can copy the slot used in the
first backup, then both nodes could consume it. That looks useful to
me to make sure that both slots are based a consistent point.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2018-06-28 07:20:53 Re: Changing the autovacuum launcher scheduling; oldest table first algorithm
Previous Message Rajkumar Raghuwanshi 2018-06-28 06:38:40 Re: alter index WITH ( storage_parameter = value [, ... ] ) for partition index.