Robert Haas wrote:
> On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm. If that's the expected application environment then the patch as
>> proposed has fatal performance problems anyway, for lack of a way to
>> get rid of no-longer-referenced pg_security rows. We had been led to
>> understand that there wouldn't be all that many distinct labels in use,
>> but this seems to imply that there are going to be $bignum of them.
>> That changes pg_security leakage from a can-live-with-for-first-cut
>> issue to a must-fix-to-be-credible issue.
>
> It's worth noting that this is yet another thing that is mostly a
> problem in the context of row-level security. It seems to me that if
> security labels are only applied to tables and columns, then it will
> be possible to scan the whole database relatively quickly and find all
> the labels that are still in use, probably without breaking a sweat.
> On the other hand, when you have row-level security, it gets a lot
> harder.
Yes, I think we shoule not ignore upcoming feature, even if it is
not on time of the next release.
> I'm wondering if this problem could be solved with a sort of
> mark-and-sweep garbage collection: add a boolean column `used' to
> pg_security (which I really think out to be renamed to
> pg_selinux_context or something, and make a new table if we someday
> support Trusted Solaris or whatever). Whenever you do an OID lookup
> and find a row that says "false", do a non-transactional update and
> change it to say "true".
It seems to me reference-counter is more preferable than boolean,
at least. But it makes performance pain on writer access when it
is expanded to row-level security.
> Then you can write something which goes through and sets all the rows
> to false and then visits every row of every table in the database and
> forces OID lookups on the security ID of each. When you get done, any
> rows that still say false are unreferenced and can be killed.
>
> Also... even if there are thousands of contexts, it only matters to
> the extent that there is a lot of churn, and I'm not sure whether
> that's something that is expected. Josh Brindle, any thoughts?
Unless the security policy writer got crazy, it would be unrealistic.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>