Dear Shlok, > I have addressed the comment for 0002 patch and attached the patches. > Also, I have moved the tests in the 0002 to 0001 patch.
Thanks for updating the patch. 0002 patch seems to remove cache invalidations from publication_invalidation_cb(). Related with it, I found an issue and had a concern. 1. The replication continues even after ALTER PUBLICATION RENAME is executed. For example - assuming that a subscriber subscribes only "pub": ``` pub=# INSERT INTO tab values (1); INSERT 0 1 pub=# ALTER PUBLICATION pub RENAME TO pub1; ALTER PUBLICATION pub=# INSERT INTO tab values (2); INSERT 0 1 sub=# SELECT * FROM tab ; -- (2) should not be replicated however... a --- 1 2 (2 rows) ``` This happens because 1) ALTER PUBLICATION RENAME statement won't be invalidate the relation cache, and 2) publications are reloaded only when invalid RelationSyncEntry is found. In given example, the first INSERT creates the valid cache and second INSERT reuses it. Therefore, the pubname-check is skipped. For now, the actual renaming is done at AlterObjectRename_internal(), a generic function. I think we must implement a dedecated function to publication and must invalidate relcaches there. 2. Similarly with above, the relcache won't be invalidated when ALTER PUBLICATION OWNER TO is executed. This means that privilage checks may be ignored if the entry is still valid. Not sure, but is there a possibility this causes an inconsistency? Best regards, Hayato Kuroda FUJITSU LIMITED
