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: Andres Freund <andres(at)anarazel(dot)de>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Copy function for logical replication slots
Date: 2019-02-20 03:26:13
Message-ID: 20190220032613.GC15532@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 19, 2019 at 05:09:33PM +0900, Masahiko Sawada wrote:
> On Tue, Feb 19, 2019 at 1:28 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Well, I'd not thought we'd do it without acquiring the other slot. But
>> that still seems to be easy enough to address, we just need to recheck
>> whether the slot still exists (with the right name) the second time we
>> acquire the spinlock?
>
> Yeah, I think that would work. The attached patch takes this
> direction. Please review it.

+ if (XLogRecPtrIsInvalid(copy_restart_lsn) ||
+ copy_restart_lsn < src_restart_lsn ||
+ src_islogical != copy_islogical ||
+ strcmp(copy_name, NameStr(*src_name)) != 0)
+ ereport(ERROR,
+ (errmsg("could not copy logical replication slot \"%s\"",
+ NameStr(*src_name)),
+ errdetail("The source replication slot has been dropped during copy")));
+
+ /* Install copied values again */
+ SpinLockAcquire(&MyReplicationSlot->mutex);

Worth worrying about this window not reduced to zero? If the slot is
dropped between both then the same issue would arise.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Юрий Соколов 2019-02-20 03:30:31 Re: Compressed TOAST Slicing
Previous Message Robert Haas 2019-02-20 03:17:10 Re: Delay locking partitions during INSERT and UPDATE