Re: Logical replication - schema change not invalidating the relation cache

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Logical replication - schema change not invalidating the relation cache
Date: 2023-01-04 21:47:41
Message-ID: 2342961.1672868861@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

vignesh C <vignesh21(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-01-04 22:16:50 Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Previous Message Peter Eisentraut 2023-01-04 21:46:23 Re: Rework of collation code, extensibility