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 CAA4eK1JhpfXHZkrckNLKE+H9SMOuJLq_eGDOuy6UKnqr_Kv9Lg@mail.gmail.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Skipping logical replication transactions on subscriber side  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
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?

With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Added schema level support for publication.
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side