On Wed, Oct 27, 2021 at 10:43 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> 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?
>
Either from the error messages in the server log or from the new view
we are planning to add. I think such a case is possible during the
initial synchronization phase where apply worker went ahead then
tablesync worker by skipping to apply the changes on the corresponding
table. After that it is possible, that table sync worker failed during
copy and apply worker fails during the processing of some other rel.
Now, I think the only way to move is via LSNs. Currently, figuring out
LSNs to skip is not straight forward but improving that area is the
work of another patch.
--
With Regards,
Amit Kapila.
