On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@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