On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane <t...@sss.pgh.pa.us> 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. 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 avoided doing that for the same reasons that we've been careful to add no such cache to pg_largeobject_metadata: the number of large objects could be big enough to cause problems with backend memory consumption. Note that large objects are one of the object types to which security labels can be applied, so any concern that applies there also applies here. I have however had the thought before that it would be nice to allow for callbacks of invalidation functions of some kind even on catalogs that don't have catcaches. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
