On 2014-03-13 11:11:51 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-03-13 10:26:11 -0400, Tom Lane wrote: > >> No, because relcache doesn't store security labels to start with. > >> There's a separate catalog cache for security labels, I believe, > >> and invalidating entries in that ought to be sufficient. > > > There doesn't seem to be any form of system managed cache for security > > labels afaics. Every lookup does a index scan. I currently don't see how > > I could build a cache in userland that'd invalidate if either a) the > > underlying object changes b) the label changes. > > If there's not a catcache for pg_seclabels, I'd have no objection > to adding one.
Ok. That's an easy enough patch, would anyone object to adding that now? > As for your "userland cache" objection, you certainly > could build such a thing using the existing inval callbacks (if we > had a catcache on pg_seclabels), and in any case what have userland > caches got to do with relcache? I don't think I've said anything about relcaches being required for this. It came up in 20140313132604.gg8...@awork2.anarazel.de, but that was because we were just talking table level there, and it's a tad easier to hook into relcache invalidation callbacks than catcache ones. That said, for a relation level cache that refer's to the table's definition, you really *do* need a relcache invalidation callback, not just a catcache callback. There's a fair number of places that do a CacheInvalidateRelcache() to trigger invals. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
