Re: Add a GUC variable that control logical replication

On Thu, 28 Nov 2019 at 11:53, Michael Paquier <michael(at)paquier(dot)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