2011/7/21 Robert Haas <robertmh...@gmail.com>: > On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga <yebhavi...@gmail.com> wrote: >> Is it possible to only include the syscache on --enable-selinux >> configurations? It would imply physical data incompatibility with standard >> configurations, but that's also true for e.g. the block size. > > Not really. SECURITY LABEL is supposedly a generic facility that can > be used by a variety of providers, and the regression tests load a > dummy provider which works on any platform to test that it hasn't > gotten broken. > >> Also, the tests I did with varying bucket sizes suggested that decreasing >> the syscache to 256 didn't show a significant performance decrease compared >> to the 2048 #buckets, for the restorecon test, which hits over 3000 objects >> with security labels. My guess is that that is a fair middle of the road >> database schema size. Are you unwilling to pay the startup overhead for a >> extra 256 syscache? > > Not sure. I'd rather not, if it's easy to rejigger things so we don't > have to. I don't think this is necessarily a hard problem to solve - > it's just that no one has tried yet. > Now, I tend to implement a cache mechanism to translate ObjectAddress to security label by sepgsql module itself, rather than generic syscache, although it requires a new hook on PrepareForTupleInvalidation() as Robert suggested in this thread. Indeed, it seems to me worthwhile not to allocate memory being unused for 90% of users; from perspective of startup performance and resource consumption.
In addition, we may be potentially able to have a cache stuff well optimized to the access control of SELinux; such as cache reclaim for recently unused entries. So, I'd like to focus on the stuff in sepgsql/uavc.c right now. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
