RE: Skipping logical replication transactions on subscriber side

On Friday, January 21, 2022 2:30 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Jan 21, 2022 at 10:32 AM osumi(dot)takamichi(at)fujitsu(dot)com
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> >
> > On Friday, January 21, 2022 12:08 PM Masahiko Sawada
> <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > I've attached an updated patch that incorporated these commends as
> > > well as other comments I got so far.
> > Thank you for your update !
> >
> > Few minor comments.
> >
> > (1) trivial question
> >
> > For the users,
> > was it perfectly clear that in the cascading logical replication
> > setup, we can't selectively skip an arbitrary transaction of one upper
> > nodes, without skipping its all executions on subsequent nodes, when
> > we refer to the current doc description of v9 ?
> >
> > IIUC, this is because we don't write changes WAL either and can't
> > propagate the contents to subsequent nodes.
> >
> > I tested this case and it didn't, as I expected.
> > This can apply to other measures for conflicts, though.
> >
>
> Right, there is nothing new as the user will same effect when she uses existing
> function pg_replication_origin_advance(). So, not sure if we want to add
> something specific to this.
Okay, thank you for clarifying this !
That's good to know.

> > (3) minor question
> >
> > In the past, there was a discussion that it might be better if we
> > reset the XID according to a change of subconninfo, which might be an
> > opportunity to connect another publisher of a different XID space.
> > Currently, we can regard it as user's responsibility.
> > Was this correct ?
> >
>
> I think if the user points to another publisher, doesn't it similarly needs to
> change slot_name as well? If so, I think this can be treated in a similar way.
I see. Then, in the AlterSubscription(), switching a slot_name
doesn't affect other columns, which means this time,
we don't need some special measure for this either as well, IIUC.
Thanks !

Best Regards,
Takamichi Osumi