From: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Problem with logical replication |
Date: | 2020-05-12 09:35:27 |
Message-ID: | CA+fd4k7BCv-0GAsEU42XxokB+a0wpyQO81HMxr5S0ryFJAWd_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 11 May 2020 at 16:28, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Sun, May 10, 2020 at 07:08:03PM -0300, Euler Taveira wrote:
> > I attached a patch with the described solution. I also included a test that
> > covers this scenario.
>
> - Assert(RelationGetReplicaIndex(rel) == RelationGetRelid(idxrel));
> + Assert(GetRelationIdentityOrPK(rel) == RelationGetRelid(idxrel));
>
> Not much a fan of adding a routine to relcache.c to do the work of two
> routines already present, so I think that we had better add an extra
> condition based on RelationGetPrimaryKeyIndex, and give up on
> GetRelationIdentityOrPK() in execReplication.c.
+1
In any case, it seems to me that the comment of
build_replindex_scan_key needs to be updated.
* This is not generic routine, it expects the idxrel to be replication
* identity of a rel and meet all limitations associated with that.
For example, we can update the above:
* This is not generic routine, it expects the idxrel to be replication
* identity or primary key of a rel and meet all limitations associated
* with that.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2020-05-12 10:14:09 | Re: No core file generated after PostgresNode->start |
Previous Message | Dilip Kumar | 2020-05-12 08:31:59 | Re: refactoring basebackup.c |