On 2014-03-13 11:26:10 -0400, Robert Haas wrote:
> On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane <tgl@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