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

From osumi.takamichi@fujitsu.com
Subject RE: Skipping logical replication transactions on subscriber side
Date
Msg-id TYCPR01MB8373EDF69CED864188AFFDF1ED5B9@TYCPR01MB8373.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Friday, January 21, 2022 2:30 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Jan 21, 2022 at 10:32 AM osumi.takamichi@fujitsu.com
> <osumi.takamichi@fujitsu.com> wrote:
> >
> > On Friday, January 21, 2022 12:08 PM Masahiko Sawada
> <sawada.mshk@gmail.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


pgsql-hackers by date:

Previous
From: wenjing zeng
Date:
Subject: Re: CREATE TABLE ( .. STORAGE ..)
Next
From: Michael Paquier
Date:
Subject: Re: Extend compatibility of PostgreSQL::Test::Cluster