On Tue, Apr 12, 2022 at 5:01 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > On 2022-Apr-12, Amit Kapila wrote: > > > On Tue, Apr 12, 2022 at 3:45 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > We don't have a lock on the relation, so if it gets dropped > > > concurrently, it won't behave sanely. For example, get_rel_name() will > > > return NULL which seems incorrect to me. > > Oh, oops ... a trap for the unwary? Anyway, yes, we can disregard the > entry when get_rel_name returns null. Amended patch attached. > > > > I am not sure about this as well because you will instead do a RELOID > > > cache lookup even when there is no row filter or column list. > > I guess my assumption is that the pg_class cache is typically more > populated than other relcaches, but that's unsubstantiated. I'm not > sure if we have any way to tell which one is the more common case. > Anyway, let's do it the way you already had it. > > > It seems to me that we have a similar coding pattern in > > ExecGrant_Relation(). > > Not sure what you mean? >
I mean that it fetches the tuple from the RELOID cache and then performs relkind and other checks similar to what we are doing. I think it could also have used get_rel_relkind() but probably not done because it doesn't have a lock on the relation. -- With Regards, Amit Kapila.
