Re: Selective logical replication - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Selective logical replication
Date
Msg-id CAMsr+YG=5f-YHs0a6y-mQtmKJK9FHCSFYVec-poEzHHpXzrj4w@mail.gmail.com
Whole thread Raw
In response to Selective logical replication  (konstantin knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: Selective logical replication  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On 19 November 2015 at 16:48, konstantin knizhnik <k.knizhnik@postgrespro.ru> wrote:
Hi,

I want to use logical replication for implementing multimaster (so all nodes are both sending and receiving changes).

 
But there is one "stupid" problem: how to prevent infinite recursion and not to rereplicate replicated data.

You need replication origins, so you can tell where a change came from and in a mesh topology only send locally-originated tuples to peers.

In a circular forwarding topology you instead filter out a peer's changes when they come back around the circle to you and forward everything else.

That's exactly what the replication origins feature in 9.5 is for. It lets you associate a tuple with the node it came from. When doing logical decoding you can make decisions about whether to forward it based on your knowledge of the tuple's origin and the peer node(s).

This is trivial to implement this on top of the pglogical output plugin - we already have the hooks for origin filtering in place. All you have to do is pass information about which nodes you want to filter out or retain.

See https://github.com/2ndQuadrant/pglogical_output and the unit tests, especially the hook tests.
 
I wonder if there is some better way to prevent some particular transaction from been replicated?

Replication origins.



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

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [DESIGN] ParallelAppend
Next
From: Craig Ringer
Date:
Subject: Re: Selective logical replication