On Mon, Oct 11, 2021 at 1:00 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Sun, Oct 10, 2021 at 11:04 PM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
> >
> > On 04.10.21 02:31, Masahiko Sawada wrote:
> > > I guess disabling subscriptions on error/conflict and skipping the
> > > particular transactions are somewhat different types of functions.
> > > Disabling subscriptions on error/conflict seems likes a setting
> > > parameter of subscriptions. The users might want to specify this
> > > option at creation time. Whereas, skipping the particular transaction
> > > is a repair function that the user might want to use on the spot in
> > > case of a failure. I’m concerned a bit that combining these functions
> > > to one syntax could confuse the users.
> >
> > Also, would the skip option be dumped and restored using pg_dump? Maybe
> > there is an argument for yes, but if not, then we probably need a
> > different path of handling it separate from the more permanent options.
>
> Good point. I don’t think the skip option should be dumped and
> restored using pg_dump since the utilization of transaction ids in
> another installation is different.
>
This is a xid of publisher which subscriber wants to skip. So, even if
one restores the subscriber data in a different installation why would
it matter till it points to the same publisher?
Either way, can't we handle this in pg_dump?
--
With Regards,
Amit Kapila.
