Re: [v9.2] SECURITY LABEL on shared database object

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Kohei Kaigai <kohei(dot)kaigai(at)emea(dot)nec(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [v9.2] SECURITY LABEL on shared database object
Date: 2011-07-05 17:55:37
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Excerpts from Kohei Kaigai's message of mar jul 05 11:46:06 -0400 2011:
> > On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
> > <alvherre(at)commandprompt(dot)com> wrote:
> > > Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011:
> > >
> > >> Hmm, OK.  I guess what I'm not sure about is - how much should we
> > >> worry about the fact that this creates several more shared (and
> > >> therefore nailed?) system catalogs?  Anyone have an opinion on that?
> > >
> > > "Several"?  That would worry me, given that we currently have a small
> > > number (eight currently).  If it's just one more, I don't think it's
> > > such a big deal.  I'm not sure what you mean by nailed though -- I mean,
> > > for example pg_shdescription is shared but not nailed in the rd_isnailed
> > > sense of the word, AFAICS.
> >
> > Well, right now the patch has pg_shseclabel, and its index, plus a
> > toast table and a toast index. Not sure why we want/need the toast
> > table & index there, but the patch has 'em as of now.
> >
> As a common belief, TEXT is a variable length data type, so pg_shseclabel
> need to have its toast table. However, I don't expect the label field get
> represented as a reference to external pointer, because average length of
> security context is about 40-60 bytes much less than the threshold to
> launch toast_save_datum().
> Do I need to remove these toast table & index?

We don't have toast tables for pg_database and so on, for example, which
means that datacl cannot go over a few hundred bytes long. I think it
makes sense to not have toast tables for pg_shseclabel. Keep in mind
that the label might be compressed before it's stored out of line, which
gives you quite a bit of actual space. If a security context is over
5000 bytes in length I think you're in trouble :-)

Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-07-05 18:01:19 Re: SSI atomic commit
Previous Message Robert Haas 2011-07-05 17:15:59 Re: lazy vxid locks, v2