On Wed, Jun 16, 2021 at 9:22 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Jun 15, 2021 at 10:41 AM Amit Kapila <amit.kapila16@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.