From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.1] sepgsql - userspace access vector cache |
Date: | 2011-07-02 09:59:08 |
Message-ID: | CADyhKSVOF1eW+U-gsmac49kwOckd4gKNUnyep_Uig19UvvAY_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The attached patch re-defines pg_seclabel.provider as NameData, instead of Text,
and revert changes of catcache.c about collations; to keep consistency with the
security label support on shared objects.
All the format changes are hidden by (Get|Set)SecurityLabel(), so no
need to change
on the patch to contrib/sepgsql.
Thanks,
2011/6/13 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> 2011/6/13 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>> For syscache, length of a typical security label in selinux is
>>> less than 64 bytes. If we assume an entry consume 128bytes
>>> including Oid pairs or pointers, its consumption is 128KBytes
>>> per 1,000 of tables or others.
>>> (Do we have a way to confirm syscache status?)
>>
>> I was thinking you might start a new session, SELECT pg_backendd_pid()
>> to get the PID, use top/ps to get its memory usage; then do a bunch of
>> stuff and see how much it's grown. The difference between how much it
>> grows with and without the patch is the amount of additional memory
>> the patch consumes.
>>
> I checked memory consumption of the backend with / without
> patches. Because sepgsql_restorecon() tries to reset security
> label of all the schemas, relations, columns and procedures,
> an execution of this function is suitable to emphasize differences
> between two cases in maximum.
>
> The results shows us about 3MB of additional consumption
> in VmRSS, even if it caches all the security label of the objects
> being created in the default (3331 entries).
>
> * without patches before/after sepgsql_restorecon()
>
> VmPeak: 150812 kB -> 170864 kB
> VmSize: 150804 kB -> 154712 kB
> VmLck: 0 kB -> 0kB
> VmHWM: 3800 kB -> 22248 kB
> VmRSS: 3800 kB -> 10620 kB
> VmData: 1940 kB -> 5820 kB
> VmStk: 196 kB -> 196 kB
> VmExe: 5324 kB -> 5324 kB
> VmLib: 2468 kB -> 2468 kB
> VmPTE: 108 kB -> 120 kB
> VmSwap: 0 kB -> 0kB
>
> * with patches before/after sepgsql_restorecon()
> VmPeak: 150816 kB -> 175092 kB
> VmSize: 150808 kB -> 158804 kB
> VmLck: 0 kB -> 0 kB
> VmHWM: 3868 kB -> 25956 kB
> VmRSS: 3868 kB -> 13736 kB
> VmData: 1944 kB -> 9912 kB
> VmStk: 192 kB -> 192 kB
> VmExe: 5324 kB -> 5324 kB
> VmLib: 2472 kB -> 2472 kB
> VmPTE: 100 kB -> 124 kB
> VmSwap: 0 kB -> 0 kB
>
> Thanks,
> --
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Attachment | Content-Type | Size |
---|---|---|
pgsql-v9.2-uavc-syscache.v2.patch | application/octet-stream | 7.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2011-07-02 10:48:32 | Re: [v9.2] Fix leaky-view problem, part 1 |
Previous Message | Kohei KaiGai | 2011-07-02 09:55:01 | Re: SECURITY LABEL on shared database object |