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

From Masahiko Sawada
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAD21AoA+0OR5RBPibe7pif5wxxe8KvBaOm7pz+hTVq=G+t2V=A@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  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Wed, Oct 27, 2021 at 12:35 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.
> >
> > BTW how useful is specifying LSN instead of XID in practice? Given
> > that this skipping behavior is used to skip the particular transaction
> > (or its part of operations) in question, I’m not sure specifying LSN
> > or time is useful.
> >
>
> I think if the user wants to skip multiple xacts, she might want to
> use the highest LSN to skip instead of specifying individual xids.

I think it assumes that the situation where the user already knows
multiple transactions that cannot be applied on the subscription but
how do they know?

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Amul Sul
Date:
Subject: Re: TAP test for recovery_end_command
Next
From: Michael Paquier
Date:
Subject: Re: TAP test for recovery_end_command