Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION
От | Bharath Rupireddy |
---|---|
Тема | Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION |
Дата | |
Msg-id | CALj2ACUMFqnP7PhjWOGiiYS12gFLySpRpx9YPJHvBX2giwZs6g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION (Li Japin <japinli@hotmail.com>) |
Ответы |
Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION
RE: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION |
Список | pgsql-hackers |
On Thu, Jan 14, 2021 at 5:36 PM Li Japin <japinli@hotmail.com> wrote > Do we really need to access PUBLICATIONRELMAP in this patch? What if > we just set it to false in the else condition of (if (publish && > (relkind != RELKIND_PARTITIONED_TABLE || pub->pubviaroot))) > > Thank for you review. I agree with you, it doesn’t need to access PUBLICATIONRELMAP, since > We already get the publication oid in GetRelationPublications(relid) [1], which also access > PUBLICATIONRELMAP. If the current pub->oid does not in pubids, the publish is false, so we > do not need publish the table. +1. This is enough. > I have another question, the data->publications is a list, when did it has more then one items? IIUC, when the single table is associated with multiple publications, then data->publications will have multiple entries. Though I have not tried, we can try having two or three publications for the same table and verify that. > 0001 - change as you suggest. > 0002 - does not change. Thanks for the updated patch. I will respond to Amit's previous comment on the 0002 patch soon. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: