From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |
Date: | 2008-12-11 16:53:42 |
Message-ID: | 200812111653.mBBGrgu23004@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
> On Thursday 11 December 2008 17:04:05 Bruce Momjian wrote:
> > The idea is that the security columns will hold an OID and the OID will
> > point to a row in a table that contains the security rights/ACL for the
> > column, with multiple rows using the same rights OID.
>
> That sounds somewhat scary for a number of reasons:
>
> 1. Running out of OIDs, the main reason why we got rid of OIDs in user tables
> by default. This would essentially put them back.
>
> 2. You are implying some kind of ACL unification algorithm, to combine
> identical ACLs under one ID. How will that work, and how will it be managed?
>
> 3. The performance impact of having to look somewhere else for every row
> fetched. If you propose a cache, note that this cache has potentially one
> possible entry for every row in the database. That would need significant
> thought and tuning.
>
> 4. Size scalability of the whole thing. When using IDs as references is being
> proposed, somewhere in there is a total size limitation for a row-security
> enabled database.
>
> Even if you manage to solve #2, is this cleanup feasible to run on a database
> that has run into the limits of #4?
>
> I suppose that SELinux in the kernel addresses these issues somehow (e.g.
> caching), but what would the SQL-only solution do?
Agreed.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2008-12-11 17:11:06 | Re: posix_fadvise v22 |
Previous Message | Alvaro Herrera | 2008-12-11 16:39:29 | Re: Refactoring SearchSysCache + HeapTupleIsValid |