On Mon, Oct 11, 2021 at 1:00 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Sun, Oct 10, 2021 at 11:04 PM Peter Eisentraut > <peter.eisentr...@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.
