On 2014-03-13 11:26:10 -0400, Robert Haas wrote: > On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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.
Good point. Are you primarily worried about the size of the cache, or about the size of the queued invaldations? I guess if it's the former we could just have the cache, but not use it when looking up values. But yuck. I think it'd be cleaner to trigger invalidations on the underlying objects... > 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. Unfortunately the format catcache invalidations have is pretty tightly tied to the hash function catcaches use internally. And we need something that can be included in the WAL, otherwise it won't work on HS nodes. 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