On Wed, Jun 16, 2021 at 9:22 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Jun 15, 2021 at 10:41 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > I don't think that finding the relation involved and registering an > > > invalidation for the same will work properly. Suppose there is a > > > concurrently-running transaction which has created a new table and > > > attached a trigger function to it. You can't see any of the catalog > > > entries for that relation yet, so you can't invalidate it, but > > > invalidation needs to happen. Even if you used some snapshot that can > > > see those catalog entries before they are committed, I doubt it fixes > > > the race condition. You can't hold any lock on that relation, because > > > the creating transaction holds AccessExclusiveLock, but the whole > > > invalidation mechanism is built around the assumption that the sender > > > puts messages into the shared queue first and then releases locks, > > > while the receiver first acquires a conflicting lock and then > > > processes messages from the queue. > > > > Won't such messages be proceesed at start transaction time > > (AtStart_Cache->AcceptInvalidationMessages)? > > Only if they show up in the queue before that. But there's nothing > forcing that to happen. You don't seem to understand how important > heavyweight locking is to the whole shared invalidation message > system.... >
I have responded about heavy-weight locking stuff in my next email [1] and why I think the approach I mentioned will work. I don't deny that I might be missing something here. [1] - https://www.postgresql.org/message-id/CAA4eK1%2BT2CWqp40YqYttDA1Skk7wK6yDrkCD5GZ80QGr5ze-6g%40mail.gmail.com -- With Regards, Amit Kapila.
