On Fri, Sep 2, 2011 at 12:38 PM, Kohei Kaigai wrote:
>> I've committed this, but I still think it would be helpful to revise
>> that comment. The turn "boosted up" is not very precise or
>> informative. Could you submit a separate, comment-only patch to
>> improve this?
>>
> I tried to put more
On Tue, Sep 6, 2011 at 4:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera
>> wrote:
>>> Pity we can't use git notes.
>
>> I spent some time looking at this this morning, and my reaction is
>> yaggh!!
>
> Yeah, we had this same discussion si
Robert Haas writes:
> On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera
> wrote:
>> Pity we can't use git notes.
> I spent some time looking at this this morning, and my reaction is
> yaggh!!
Yeah, we had this same discussion six weeks ago.
http://archives.postgresql.org/pgsql-hackers/2
On 09/06/2011 09:35 AM, Robert Haas wrote:
[git notes is more than cumbersome ]
As much as I'd like to have something like this, I'm inclined to think
that it will take a whole lot more time to get this facility working
than it's really worth. Unless someone has a strong opinion the other
w
On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera
wrote:
>> > Pity we can't use git notes.
>>
>> Well, I guess there's no law that says we can't. Should I give it a try?
>
> I don't see why not :-) (But my guess is that you're going to need to
> publish some pull and push instructions, because I g
On 2011-09-06 04:55, Robert Haas wrote:
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
wrote:
Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
I didn't see my name as one of the reviewers in the commit message. If tha
Excerpts from Robert Haas's message of lun sep 05 23:55:33 -0300 2011:
> On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
> >> On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
> >> > On 2011-09-01 14:40, Robert H
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
>> On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
>> > On 2011-09-01 14:40, Robert Haas wrote:
>> >>
>> >> userspace avc.
>> >> I've committed this, but I still thi
Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
> On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
> > On 2011-09-01 14:40, Robert Haas wrote:
> >>
> >> userspace avc.
> >> I've committed this, but I still think it would be helpful to revise
> >> that comment. The turn "
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
> On 2011-09-01 14:40, Robert Haas wrote:
>>
>> userspace avc.
>> I've committed this, but I still think it would be helpful to revise
>> that comment. The turn "boosted up" is not very precise or
>> informative. Could you submit a separate, co
On 2011-09-01 14:40, Robert Haas wrote:
userspace avc.
I've committed this, but I still think it would be helpful to revise
that comment. The turn "boosted up" is not very precise or
informative. Could you submit a separate, comment-only patch to
improve this?
I didn't see my name as one of
> I've committed this, but I still think it would be helpful to revise
> that comment. The turn "boosted up" is not very precise or
> informative. Could you submit a separate, comment-only patch to
> improve this?
>
I tried to put more detailed explanation about the logic of do { ... } while
loo
> On Fri, Aug 26, 2011 at 5:32 AM, Kohei KaiGai wrote:
> > Yes. It also caches an expected security label when a client being
> > labeled as "scontext" tries to execute a procedure being labeled as
> > "tcontext", to reduce number of system call invocations on fmgr_hook
> > and needs_fmgr_hook.
>
On Fri, Aug 26, 2011 at 5:32 AM, Kohei KaiGai wrote:
> Yes. It also caches an expected security label when a client being
> labeled as "scontext" tries to execute a procedure being labeled as
> "tcontext", to reduce number of system call invocations on fmgr_hook
> and needs_fmgr_hook.
> If the exp
Robert, Thanks for your reviewing.
> For me, the line you removed from dml.out causes the regression tests to fail.
>
Fixed. Why did I removed this line??
> I don't understand what this is going for:
>
> + /*
> + * To boost up trusted procedure checks on db_procedure object
> +
On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai wrote:
> BTW, what is the current status of this patch?
> The status of contrib/sepgsql part is unclear for me, although we agreed that
> syscache is suitable mechanism for security labels.
Sorry it's taken me a while to get around to looking at this.
On Fri, Aug 19, 2011 at 11:40 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane wrote:
>>> No objection to fixing or backpatching this, but I'm not seeing the
>>> argument for treating this module differently from contrib/xml2.
>
>> Because I screwed it up a
On Fri, Aug 19, 2011 at 11:46 AM, Tom Lane wrote:
> Kohei Kaigai writes:
>>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>>> Well, they should get at least a warning from referencing undefined
>>> functions, no?
>
>> Yes. User should notice warning messages due to undefined symbols.
>> I'm not cer
Kohei Kaigai writes:
>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Well, they should get at least a warning from referencing undefined
>> functions, no?
> Yes. User should notice warning messages due to undefined symbols.
> I'm not certain whether it makes sense to add -Werror here, or not.
H
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: 19. August 2011 16:34
> To: Kohei Kaigai
> Cc: Robert Haas; Kohei KaiGai; Yeb Havinga; PgHacker
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> Kohei Kaigai w
Robert Haas writes:
> On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane wrote:
>> No objection to fixing or backpatching this, but I'm not seeing the
>> argument for treating this module differently from contrib/xml2.
> Because I screwed it up accidentally for sepgsql, and I can't screw it
> up for xml
Kohei Kaigai writes:
> One point I'm worrying about is a case when contrib/sepgsql is compiled
> with older libselinux than minimum requirement. In this case, we may not
> notice the broken module unless user tries to load it actually.
> Is there a good idea to ensure compile failure when we try t
On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane wrote:
> Robert Haas writes:
>> On further review, if the initial configure was done without
>> --with-libxml, xml2 is doomed anyway.
>
> True, but it's still possible to build a shlib that will then not work.
> I just did, after manually supplying the r
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: 19. August 2011 15:55
> To: Tom Lane
> Cc: Kohei KaiGai; Kohei Kaigai; Yeb Havinga; PgHacker
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On Fri, Aug 19,
Robert Haas writes:
> On further review, if the initial configure was done without
> --with-libxml, xml2 is doomed anyway.
True, but it's still possible to build a shlib that will then not work.
I just did, after manually supplying the right -I switch:
make PROFILE=-I/usr/include/libxml2
Now ad
On Fri, Aug 19, 2011 at 10:31 AM, Robert Haas wrote:
> On Fri, Aug 19, 2011 at 10:20 AM, Tom Lane wrote:
>>> Why not just:
>>
>>> SHLIB_LINK = -lselinux
>>
>> I wouldn't have any particular objection to that (although I think it's
>> supposed to be += here).
>
> Oh, right.
>
>> I don't see that a
On Fri, Aug 19, 2011 at 10:20 AM, Tom Lane wrote:
>> Why not just:
>
>> SHLIB_LINK = -lselinux
>
> I wouldn't have any particular objection to that (although I think it's
> supposed to be += here).
Oh, right.
> I don't see that any of the other changes
> Kaigai proposed are helpful, though.
I w
Robert Haas writes:
> On Fri, Aug 19, 2011 at 9:59 AM, Tom Lane wrote:
>> This patch seems unnecessary to me.
> Hmm. I see now that it's parallel, but I find it pretty confusing
> that building sepgsql without specifying --with-selinux results in a
> shared library that seems to compile OK but
On Fri, Aug 19, 2011 at 9:59 AM, Tom Lane wrote:
> Kohei KaiGai writes:
>> 2011/8/18 Robert Haas :
>>> Actually, as I look at this more, I think this build system is
>>> completely mis-designed. Given that you want to build sepgsql,
>>> selinux is not an optional feature. So the stuff in
>>> co
Kohei KaiGai writes:
> 2011/8/18 Robert Haas :
>> Actually, as I look at this more, I think this build system is
>> completely mis-designed. Given that you want to build sepgsql,
>> selinux is not an optional feature. So the stuff in
>> contrib/sepgsql/Makefile that is intended to link against l
efix=/usr/local/sepgsql instead?
>
> Thanks,
> --
> NEC Europe Ltd, SAP Global Competence Center
> KaiGai Kohei
>
>
>> -Original Message-
>> From: Robert Haas [mailto:robertmh...@gmail.com]
>> Sent: 18. August 2011 18:22
>> To: Kohei Kaigai
>>
2011/8/18 Robert Haas :
> On Thu, Aug 18, 2011 at 1:17 PM, Kohei Kaigai
> wrote:
>>> That's lame. I think we need to patch contrib/sepgsql so that it
>>> fails to build in that case, rather than building and then not
>>> working.
>>>
>> It might be the following fix, but I have no idea to genera
On Thu, Aug 18, 2011 at 1:17 PM, Kohei Kaigai wrote:
>> That's lame. I think we need to patch contrib/sepgsql so that it
>> fails to build in that case, rather than building and then not
>> working.
>>
> It might be the following fix, but I have no idea to generate an error when
> $(with_selinux
ence Center
KaiGai Kohei
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: 18. August 2011 18:22
> To: Kohei Kaigai
> Cc: Yeb Havinga; PgHacker; Kohei KaiGai
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On
On Thu, Aug 18, 2011 at 1:00 PM, Robert Haas wrote:
> [more problems]
OK, I'm giving up for now. I hit two more snags:
1. chkselinuxenv uses "which", and a Fedora 15 minimal install doesn't
include that. I fixed that by installing "which", but maybe we ought
to be looking for a way to eliminat
om]
> Sent: 18. August 2011 17:53
> To: Kohei Kaigai
> Cc: Yeb Havinga; PgHacker; Kohei KaiGai
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas wrote:
> > On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai
&g
On Thu, Aug 18, 2011 at 12:52 PM, Robert Haas wrote:
> On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas wrote:
>> On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai
>> wrote:
>>> The attached patch is revised userspace-avc patch.
>>>
>>> List of updates:
>>> - The GUC of sepgsql.avc_threshold was remov
On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas wrote:
> On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai
> wrote:
>> The attached patch is revised userspace-avc patch.
>>
>> List of updates:
>> - The GUC of sepgsql.avc_threshold was removed.
>> - "char *ucontext" of avc_cache was replaced by "bool t
On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai wrote:
> The attached patch is revised userspace-avc patch.
>
> List of updates:
> - The GUC of sepgsql.avc_threshold was removed.
> - "char *ucontext" of avc_cache was replaced by "bool tcontext_is_valid".
> - Comments added onto static variables
> -
2011/8/5 Robert Haas :
> On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai wrote:
>> BTW, what is the current status of this patch?
>
> I think it's waiting for me to get around to reviewing it. Sorry,
> been busy :-(
>
Thanks for your efforts.
>> The status of contrib/sepgsql part is unclear for
On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai wrote:
> BTW, what is the current status of this patch?
I think it's waiting for me to get around to reviewing it. Sorry,
been busy :-(
> The status of contrib/sepgsql part is unclear for me, although we agreed that
> syscache is suitable mechani
BTW, what is the current status of this patch?
The status of contrib/sepgsql part is unclear for me, although we agreed that
syscache is suitable mechanism for security labels.
Thanks,
2011/7/22 Kohei KaiGai :
> 2011/7/22 Yeb Havinga :
>> On 2011-07-22 11:55, Kohei Kaigai wrote:
>>>
2) Also
On 2011-07-21 11:29, Kohei Kaigai wrote:
The attached patch is revised userspace-avc patch.
List of updates:
- The GUC of sepgsql.avc_threshold was removed.
- "char *ucontext" of avc_cache was replaced by "bool tcontext_is_valid".
- Comments added onto static variables
- Comments of sepgsql_avc_
2011/7/22 Yeb Havinga :
> On 2011-07-22 11:55, Kohei Kaigai wrote:
>>
>>> 2) Also I thought if it could work to not remember tcontext is valid, but
>>> instead remember the consequence,
>>> which is that it is replaced by "unlabeled". It makes the avc_cache
>>> struct shorter and the code somewhat
On 2011-07-22 11:55, Kohei Kaigai wrote:
2) Also I thought if it could work to not remember tcontext is valid, but
instead remember the consequence,
which is that it is replaced by "unlabeled". It makes the avc_cache struct
shorter and the code somewhat
simpler.
Here is a reason why we hold
> -Original Message-
> From: Yeb Havinga [mailto:yebhavi...@gmail.com]
> Sent: 22. Juli 2011 10:23
> To: Kohei Kaigai
> Cc: Robert Haas; PgHacker; Kohei KaiGai
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On 2011-07-21 11:29, Koh
2011/7/21 Robert Haas :
> On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga 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 re
2011/7/21 Yeb Havinga :
>
>> 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.
>>
>> Also, the tests I did with varying bucket sizes suggested
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.
Also, the tests I did with varying bucket sizes suggested that
decreasing the syscache to 2
On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga 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 suppose
On 2011-07-21 15:03, Robert Haas wrote:
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga wrote:
Besides that I have to admit having problems understanding why the 5MB cache
for pg_seclabel is a problem; it's memory consumption is lineair only to the
size of the underlying database. (in contrast wi
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga wrote:
> Is there a way to dump syscache statistics like there is for
> MemoryContext..Stats (something - gdb helped me there)?
I don't know of one.
> Besides that I have to admit having problems understanding why the 5MB cache
> for pg_seclabel is a
On 2011-07-21 00:08, Robert Haas wrote:
On Wed, Jul 20, 2011 at 4:48 PM, Tom Lane wrote:
Kohei Kaigai writes:
I'd like to have a discussion about syscache towards next commit-fest.
The issues may be:
- Initial bucket allocation on most cases never be referenced.
- Reclaim cache entries on
On Wed, Jul 20, 2011 at 4:48 PM, Tom Lane wrote:
> Kohei Kaigai writes:
>> I'd like to have a discussion about syscache towards next commit-fest.
>> The issues may be:
>> - Initial bucket allocation on most cases never be referenced.
>> - Reclaim cache entries on growing up too large.
>
> There
Kohei Kaigai writes:
> I'd like to have a discussion about syscache towards next commit-fest.
> The issues may be:
> - Initial bucket allocation on most cases never be referenced.
> - Reclaim cache entries on growing up too large.
There used to be support for limiting the number of entries in a
On Wed, Jul 20, 2011 at 4:19 PM, Robert Haas wrote:
> On Wed, Jul 20, 2011 at 4:06 PM, Josh Berkus wrote:
>> Kaigai,
>>
>>> I'd like to have a discussion about syscache towards next commit-fest.
>>> The issues may be:
>>> - Initial bucket allocation on most cases never be referenced.
>>> - Recl
On Wed, Jul 20, 2011 at 4:06 PM, Josh Berkus wrote:
> Kaigai,
>
>> I'd like to have a discussion about syscache towards next commit-fest.
>> The issues may be:
>> - Initial bucket allocation on most cases never be referenced.
>> - Reclaim cache entries on growing up too large.
>
> Should I move
Kaigai,
> I'd like to have a discussion about syscache towards next commit-fest.
> The issues may be:
> - Initial bucket allocation on most cases never be referenced.
> - Reclaim cache entries on growing up too large.
Should I move this patch to the next CF?
--
Josh Berkus
PostgreSQL Experts
> On Wed, Jul 20, 2011 at 9:47 AM, Yeb Havinga wrote:
> > * I run SELECT sepgsql_restorecon(NULL) and saw comparable numbers in speed
> > gain and also backend process memory increase as indicated by KaiGai-san.
> > The vmsize without the patch increases from running restorecon 3864kB, with
> > th
> On Wed, Jul 20, 2011 at 12:04 PM, Kohei Kaigai
> wrote:
> > The sepgsql_restorecon(NULL) assigns default security label on all the
> > database objects being controlled, thus, its workload caches security
> > label (including text data) of these objects.
> > So, ~5MB of difference is an upper li
> On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
> wrote:
> > One question is why InitCatalogCache() should be invoked from
> > InitPostgres()?
> > If we initialize syscache on starting up postmaster process, I think
> > all the syscache buckets will be ready on child process forks, and
> > unuse
On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
wrote:
> One question is why InitCatalogCache() should be invoked from InitPostgres()?
> If we initialize syscache on starting up postmaster process, I think
> all the syscache buckets will be ready on child process forks, and
> unused syscache does n
On Wed, Jul 20, 2011 at 12:04 PM, Kohei Kaigai
wrote:
> The sepgsql_restorecon(NULL) assigns default security label on all the
> database objects being controlled, thus, its workload caches security
> label (including text data) of these objects.
> So, ~5MB of difference is an upper limit of sysca
Yeb, Thanks for your volunteering.
> On 2011-07-14 21:46, Kohei KaiGai wrote:
> > Sorry, the syscache part was mixed to contrib/sepgsql part
> > in my previous post.
> > Please see the attached revision.
> >
> > Although its functionality is enough simple (it just reduces
> > number of system-call
On 2011-07-20 16:54, Robert Haas wrote:
As to the first point, the other big problem with adding a syscache
here is that it could get really big. I've worried about that issue
previously, and Yev's perplexity about where the memory is going is
not too reassuring.
Yeah I just realized that #buck
On Wed, Jul 20, 2011 at 9:47 AM, Yeb Havinga wrote:
> * I run SELECT sepgsql_restorecon(NULL) and saw comparable numbers in speed
> gain and also backend process memory increase as indicated by KaiGai-san.
> The vmsize without the patch increases from running restorecon 3864kB, with
> the patch is
On 2011-07-14 21:46, Kohei KaiGai wrote:
Sorry, the syscache part was mixed to contrib/sepgsql part
in my previous post.
Please see the attached revision.
Although its functionality is enough simple (it just reduces
number of system-call invocation), its performance
improvement is obvious.
So, I
2011/7/19 Yeb Havinga :
> On 2011-07-19 22:39, Heikki Linnakangas wrote:
>>
>> On 19.07.2011 12:28, Yeb Havinga wrote:
>>>
>>> On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (
On 2011-07-19 22:39, Heikki Linnakangas wrote:
On 19.07.2011 12:28, Yeb Havinga wrote:
On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (libselinux-2.0.99 or later).
My recommendation is Fedora
On 19.07.2011 12:28, Yeb Havinga wrote:
On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (libselinux-2.0.99 or later).
My recommendation is Fedora 15, instead.
Installing right now, thanks for
On 2011-07-19 12:10, Kohei Kaigai wrote:
See the attached patch, that contains other 3 documentation updates.
I looked at the patch and the additions look good, though I didn't
actually apply it yet.
thanks
Yeb
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
> >> /etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid
> >> object
> >> type db_blobs
> > It is not an error, but just a notification to inform users that
> > sepgsql_contexts
> > file contains invalid lines. It is harmless, so we can ignore them.
> > I don't think sepgsql.sgml
On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (libselinux-2.0.99 or later).
My recommendation is Fedora 15, instead.
Installing right now, thanks for the heads up!
/etc/selinux/targeted/con
2011/7/18 Robert Haas :
> On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai wrote:
>>> 3) sepgsql is currently a bit hard to find in the documentation.
>>> www.postgresql.org website search doesn't find sepgsql and selinux only
>>> refers to an old PostgreSQL redhat bug in 2005 on bugzilla.redhat.com.
On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai wrote:
>> 3) sepgsql is currently a bit hard to find in the documentation.
>> www.postgresql.org website search doesn't find sepgsql and selinux only
>> refers to an old PostgreSQL redhat bug in 2005 on bugzilla.redhat.com. I had
>> to manually remembe
Yeb, Thanks for your volunteering.
2011/7/18 Yeb Havinga :
> Hello KaiGai-san,
>
> I've been preparing to review this patch by reading both pgsql-hackers
> history on sepgsql, and also the RHEL 6 guide on SELinux this weekend, today
> I installed GIT HEAD with --with-selinux on Scientific Linux 6,
Hello KaiGai-san,
I've been preparing to review this patch by reading both pgsql-hackers
history on sepgsql, and also the RHEL 6 guide on SELinux this weekend,
today I installed GIT HEAD with --with-selinux on Scientific Linux 6,
developer installation, so far almost everything looking good.
On 2011-07-14 21:46, Kohei KaiGai wrote:
Sorry, the syscache part was mixed to contrib/sepgsql part
in my previous post.
Please see the attached revision.
Although its functionality is enough simple (it just reduces
number of system-call invocation), its performance
improvement is obvious.
So, I
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
2011/6/13 Robert Haas :
> On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai 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
On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai 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
On Thu, Jun 9, 2011 at 3:09 PM, Kohei KaiGai 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
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai wrote:
>> 2011/6/9 Stephen Frost :
>>> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enables to
>
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai wrote:
>> 2011/6/9 Robert Haas :
>>> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enabl
On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai wrote:
> 2011/6/9 Stephen Frost :
>> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>>> The only modification by this patch to the core routine is a new
>>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>>> reference security label o
On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai wrote:
> 2011/6/9 Robert Haas :
>> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
>>> The only modification by this patch to the core routine is a new
>>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>>> reference security
2011/6/9 Stephen Frost :
> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>> The only modification by this patch to the core routine is a new
>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>> reference security label of the object using syscache interface.
>
> Perhaps I'm missi
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
>> The only modification by this patch to the core routine is a new
>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>> reference security label of the object using syscache interface.
>
> I believe
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> The only modification by this patch to the core routine is a new
> syscache for pg_seclabel system catalog. The SECLABELOID enables to
> reference security label of the object using syscache interface.
Perhaps I'm missing it, but.. why is this necessar
On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
> The only modification by this patch to the core routine is a new
> syscache for pg_seclabel system catalog. The SECLABELOID enables to
> reference security label of the object using syscache interface.
I believe we decided against that previou
90 matches
Mail list logo
