On Thu, Jun 17, 2021 at 8:29 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Jun 17, 2021 at 4:54 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > 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 > > I mean I saw that but I don't see how it addresses the visibility > issue. >
I thought if we scan a system catalog using DirtySnapshot, then we should be able to find such a relation. But, if the system catalog is updated after our scan then surely we won't be able to see it and in that case, we won't be able to send invalidation. Now, say if the rel is not visible to us because of the snapshot we used or due to some race condition then we won't be able to send the invalidation but why we want to consider it worse than the case where we miss such invalidations (invalidations due to change of parallel-safe property) when the insertion into relation is in-progress. > There could be a relation that is not visible to your snapshot > and upon which AccessExclusiveLock is held which needs to be > invalidated. You can't lock it because it's AccessExclusiveLock'd > already. > Yeah, the session in which we are doing Alter Function won't be able to lock it but it will wait for the AccessExclusiveLock on the rel to be released because it will also try to acquire it before sending invalidation. -- With Regards, Amit Kapila.
