From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.1] sepgsql - userspace access vector cache |
Date: | 2011-06-12 01:31:43 |
Message-ID: | BANLkTikraGVBtP27tcMLkiHcA2du8+kn6Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 9, 2011 at 3:09 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> Here is two level lookups.
> The first is from object identifiers to security label; it can be boosted
> using syscache mechanism. The second is from security labels to
> access control decision; it can be boosted using userspace avc.
OK. Let's have two separate patches, then.
Thinking a bit more about the issue of adding a syscache, I suspect
it's probably OK to use that mechanism rather than inventing something
more complicated that can kick out entries on an LRU basis. Even if
you accessed a few tens of thousands of entries, the cache shouldn't
grow to more than a few megabytes. And that's presumably going to be
rare, and could happen with other types of objects (such as tables)
using the existing system caches. So I guess it's probably premature
optimization to worry about the issue now.
I would, however, like to see some performance results indicating how
much the cache helps, and how much memory it eats up in the process.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2011-06-12 01:56:16 | Re: procpid? |
Previous Message | Robert Haas | 2011-06-12 01:23:52 | Re: procpid? |