Re: [HACKERS] Logical replication in the same cluster - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [HACKERS] Logical replication in the same cluster
Date
Msg-id dcb5e17f-d5f7-9220-c4f9-2f9bf464a2a3@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Logical replication in the same cluster  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Logical replication in the same cluster  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 02/05/17 04:14, Peter Eisentraut wrote:
> On 4/30/17 20:31, Andres Freund wrote:
>> On 2017-04-26 23:41:51 +0200, Petr Jelinek wrote:
>>> Yes that's result of how logical replication slots work, the transaction
>>> that needs to finish is your transaction. It can be worked around by
>>> creating the slot manually via the SQL interface for example and create
>>> the subscription using WITH (NOCREATE SLOT, SLOT NAME = 'your slot') .
>>
>> Is there any chance the creation of the slot could be moved ahead, to
>> before an xid has been assigned?
> 
> The trend has rather been to do most of the stuff before creating the
> slot, so that all the error checking is done.  See for example
> dcb39c37c1d3b90115e1501af8efb7af59c341c3.
> 

Yes because otherwise we risk leaving slot on the upstream if the
command fails downstream. We could move the slot creation outside of tx
as I proposed, then we risk leaving subscription downstream without slot
upstream though but I think that's less of a issues from user
friendliness and mainly safety (slot reserves wal and global catalog
xmin while subscription does not reserve anything except the name of the
subscription).

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
Next
From: Vladimir Borodin
Date:
Subject: Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range