Re: Logical replication - schema change not invalidating the relation cache
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: vignesh C <vignesh21@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Dilip Kumar <dilipbalaut@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-01-04T21:47:41Z
Lists: pgsql-hackers
vignesh C <vignesh21@gmail.com> writes: > [ v3-0001-Fix-for-invalidating-logical-replication-relation.patch ] (btw, please don't send multiple patch versions with the same number, it's very confusing.) I looked briefly at this patch. I wonder why you wrote a whole new callback function instead of just using rel_sync_cache_publication_cb for this case too. The bigger picture here though is that in examples such as the one you gave at the top of the thread, it's not very clear to me that there's *any* principled behavior. If the connection between publisher and subscriber tables is only the relation name, fine ... but exactly which relation name applies? If you've got a transaction that is both inserting some data and renaming the table, it's really debatable which insertions should be sent under which name(s). So how much should we actually care about such cases? Do we really want to force a cache flush any time somebody changes a (possibly unrelated) pg_namespace entry? We could be giving up significant performance and not accomplishing much except changing from one odd behavior to a different one. regards, tom lane
Commits
-
Invalidate pgoutput's replication-decisions cache upon schema rename.
- cd4b2334db49 16.0 landed
-
Add wait_for_subscription_sync for TAP tests.
- 0c20dd33db16 16.0 cited
-
Unify PostgresNode's new() and get_new_node() methods
- 201a76183e20 15.0 cited