On Tue, Jun 15, 2021 at 8:11 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Jun 14, 2021 at 9:08 PM Robert Haas <robertmh...@gmail.com> wrote: > > > > On Mon, Jun 14, 2021 at 2:32 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > Yeah, this could be one idea but I think even if we use pg_proc OID, > > > we still need to check all the rel cache entries to find which one > > > contains the invalidated OID and that could be expensive. I wonder > > > can't we directly find the relation involved and register invalidation > > > for the same? We are able to find the relation to which trigger > > > function is associated during drop function via findDependentObjects > > > by scanning pg_depend. Assuming, we are able to find the relation for > > > trigger function by scanning pg_depend, what kinds of problems do we > > > envision in registering the invalidation for the same? > > > > 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)? >
Even if accept invalidation at the start transaction time, we need to accept and execute it after taking a lock on relation to ensure that relation doesn't change afterward. I think what I mentioned didn't break this assumption because after finding a relation we will take a lock on it before registering the invalidation, so in the above scenario, it should wait before registering the invalidation. -- With Regards, Amit Kapila.
