Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAA4eK1L0YHZ-+DUL7p2nwu3pC5wg_FsM5hELiy+Db-rPZovR-g@mail.gmail.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Skipping logical replication transactions on subscriber side  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Thu, Oct 28, 2021 at 10:56 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Thu, Oct 28, 2021 at 1:29 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Wed, Oct 27, 2021 at 4:07 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Wed, Oct 27, 2021 at 8:32 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > >
> > > > On Tue, Oct 26, 2021 at 7:29 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > > >
> > > > > You have a point. The other alternatives on this line could be:
> > > > >
> > > > > Alter Subscription <sub_name> SKIP ( subscription_parameter [=value] [, ... ] );
> > > > >
> > > > > where subscription_parameter can be one of:
> > > > > xid = <xid_val>
> > > > > lsn = <lsn_val>
> > > > > ...
> > > >
> > > > Looks better.
> > > >
> > >
> > > If we want to follow the above, then how do we allow users to reset
> > > the parameter? One way is to allow the user to set xid as 0 which
> > > would mean that we reset it. The other way is to allow SET/RESET
> > > before SKIP but not sure if that is a good option.
> > >
> >
> > After thinking some more on this, I think it is better to not use
> > SET/RESET keyword here. I think we can use a model similar to how we
> > allow setting some of the options in Alter Database:
> >
> > # Set the connection limit for a database:
> > Alter Database akapila WITH connection_limit = 1;
> > # Reset the connection limit
> > Alter Database akapila WITH connection_limit = -1;
> >
> > Thoughts?
>
> Agreed.
>
> Another thing I'm concerned is that the syntax "SKIP (
> subscription_parameter [=value] [, ...])" looks like we can specify
> multiple options for example, "SKIP (xid = '100', lsn =
> '0/12345678’)”. Is there a case where we need to specify multiple
> options? Perhaps when specifying the target XID and operations for
> example, “SKIP (xid = 100, action = ‘insert, update’)”?
>

Yeah, or maybe prepared transaction identifier and actions. BTW, if we
want to proceed without the SET/RESET keyword then you can prepare the
SKIP xid patch as the second in the series and we can probably work on
the RESET syntax as a completely independent patch.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Gilles Darold
Date:
Subject: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side