Re: Add a GUC variable that control logical replication - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Add a GUC variable that control logical replication
Date
Msg-id CAMsr+YEZJu8Qz5iAWJ-o9omow2jrrfWJQ3=w1JbVYzt1V=4WKA@mail.gmail.com
Whole thread Raw
In response to Re: Add a GUC variable that control logical replication  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, 28 Nov 2019 at 11:53, Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Nov 06, 2019 at 10:01:43PM +0800, Quan Zongliang wrote:
> What the user needs is the same replication link that selectively skips some
> transactions. And this choice only affects transactions that are doing bulk
> delete sessions. The operations of other sessions are not affected and can
> continue to output replication messages.
> For example, session 1 wants to bulk delete 1 million old data from the T1
> table, which can be done without replication. At the same time, session 2
> deletes 10 records from T1, which is expected to be passed on through
> replication.
> Therefore, the two decoders can not meet this requirement. It is also
> inappropriate to temporarily disable subscriptions because it skips all
> transactions for a certain period of time.

Hmm.  The patch discussed on this thread does not have much support
from Peter and Craig, so I am marking it as RwF.


Yeah. I'm not against it as such. But I'd like to either see it work by exposing the ability to use DoNotReplicateId to SQL or if that's not satisfactory, potentially replace that mechanism with the newly added one and emulate DoNotReplicateId for BC.

I don't want two orthogonal ways to say "don't consider this for logical replication".
--
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Missing data_sync_elevel() for some calls of pg_fsync()?
Next
From: Michael Paquier
Date:
Subject: Re: pgbench -i progress output on terminal