Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION
От | Dilip Kumar |
---|---|
Тема | Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION |
Дата | |
Msg-id | CAFiTN-udwuc_h0TaFrSEKb-Yo1vVvkjz9TDRw7VE3P-KiPSGbQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Список | pgsql-hackers |
On Wed, Jan 13, 2021 at 3:08 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > On Wed, Jan 13, 2021 at 2:53 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > IIUC the logical replication only replicate the tables in publication, I think > > > when the tables that aren't in publication should not be replicated. > > > > > > Attached the patch that fixes it. Thought? > > > > > > > Instead of doing this, I would expect that the RelationSyncCache entry > > should be removed when the relation is dropped from the publication. > > So if that is done then it will reload the publication and then it > > will not find that that relation as published and it will ignore the > > changes. But the patch doesn't seem to be exactly on that line. Am I > > missing something here? > > IIUC, it's not possible to remove the cache entry inside > rel_sync_cache_publication_cb, because we don't receive the relid of > the alter publication .. dropped relation in the invalidation > callback. See the below comment, Hmm, yeah because nothing changed to the relation the change is for the publication so the invalidation is not registered for the relation entry. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: