Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION
Japin Li <japinli@hotmail.com>
From: japin <japinli@hotmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL Hackers
<pgsql-hackers@lists.postgresql.org>
Date: 2021-01-12T11:53:24Z
Lists: pgsql-hackers
On Tue, 12 Jan 2021 at 19:32, Bharath Rupireddy wrote: > On Tue, Jan 12, 2021 at 4:47 PM Li Japin <japinli@hotmail.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? > > With that change, we don't get the behaviour that's stated in the > document - "The ADD TABLE and DROP TABLE clauses will add and remove > one or more tables from the publication. Note that adding tables to a > publication that is already subscribed to will require a ALTER > SUBSCRIPTION ... REFRESH PUBLICATION action on the subscribing side in > order to become effective" - > https://www.postgresql.org/docs/devel/sql-alterpublication.html. > The documentation only emphasize adding tables to a publication, not include dropping tables from a publication. > The publisher stops sending the tuples whenever the relation gets > dropped from the publication, not waiting until alter subscription ... > refresh publication on the subscriber. > If we want to wait the subscriber executing alter subscription ... refresh publication, maybe we should send some feedback to walsender. How can we send this feedback to walsender in non-walreceiver process? > With Regards, > Bharath Rupireddy. > EnterpriseDB: http://www.enterprisedb.com -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
Commits
-
Fix ALTER PUBLICATION...DROP TABLE behavior.
- 40ab64c1ec1c 14.0 landed
-
Fix initialization of RelationSyncEntry for streaming transactions.
- 69bd60672af6 14.0 cited