Robert Haas wrote:
> Streaming Replication
> I think reviewing is not as far advanced, but I'm not sure.
I started reviewing Streaming Replication on Monday, but got dragged
into other stuff on the following day. I'm planning to continue that on
Monday again.
--
Heikki Linnakangas
Enterprise
I'd like to summary about the framework.
* Functionalities
The ACE framework hosts both of the default PG checks and upcoming
enhanced securities. We can build a binary with multiple enhanced
security features, but user can choose one from them at most due
to the security label management.
So, i
Bruce Momjian writes:
> A more difficult issue is whether we should preserve the fact that
> plpgsql was _removed_ in the pg_dump output, i.e, if someone removes
> plpgsql from a database, do we issue a DROP LANGUAGE in pg_dump? I
> don't remember us having to deal with anything like this before.
Takahiro Itagaki wrote:
KaiGai Kohei wrote:
We have to reference pg_largeobject_metadata to check whether a certain
large objct exists, or not.
It is a case when we create a new large object, but write nothing.
OK, that makes sense.
In addition of the patch, we also need to fix pg_rest
Tom Lane escreveu:
> I'm not sure there is any really nice solution within the confines of
> plain ASCII text output. There was an interesting approach online
> at http://explain-analyze.info, but that site seems to be down now :-(
>
Estimation error is one of the ideas. The other ones I have in
On Sat, Dec 12, 2009 at 11:31 AM, Simon Riggs wrote:
> On Fri, 2009-12-11 at 20:38 -0500, Robert Haas wrote:
>
>> I'm not quite sure where we stand with these two patches. My
>> impression is that many of the outstanding TODO items in Hot Standby
>> have been fixed, and I'm not sure what remains.
Tom Lane wrote:
> Bruce Momjian writes:
> > I installed PL/pgSQL by default via initdb with the attached patch. The
> > only problem is that pg_dump still dumps out the language creation:
> > CREATE PROCEDURAL LANGUAGE plpgsql;
> > ALTER PROCEDURAL LANGUAGE plpgsql OWNER TO postgres;
> >
Bruce Momjian writes:
> Ashish wrote:
>> I am thinking about starting with the following TODO item:
>> --> Have EXPLAIN ANALYZE issue NOTICE messages when the estimated
>> and actual row counts differ by a specified percentage.
> I even have a sample patch you can use as a start, attached.
Of co
Robert Haas wrote:
> On Fri, Dec 11, 2009 at 9:05 PM, Bruce Momjian wrote:
> > Ashish wrote:
> >> I am thinking about starting with the following TODO item:
> >>
> >> --> Have EXPLAIN ANALYZE issue NOTICE messages when the estimated
> >> and actual row counts differ by a specified percentage.
> >>
On Fri, 2009-12-11 at 20:38 -0500, Robert Haas wrote:
> I'm not quite sure where we stand with these two patches. My
> impression is that many of the outstanding TODO items in Hot Standby
> have been fixed, and I'm not sure what remains. Streaming Replication
> I think reviewing is not as far ad
On Fri, Dec 11, 2009 at 9:05 PM, Bruce Momjian wrote:
> Ashish wrote:
>> I am thinking about starting with the following TODO item:
>>
>> --> Have EXPLAIN ANALYZE issue NOTICE messages when the estimated
>> and actual row counts differ by a specified percentage.
>>
>> I picked this because it is s
On Fri, Dec 11, 2009 at 9:00 PM, Ashish wrote:
> I am thinking about starting with the following TODO item:
>
> --> Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual
> row counts differ by a specified percentage.
>
> I picked this because it is somewhat related to query proc
Greg Smith writes:
> Tom Lane wrote:
>> It's amazing to me that we've never
>> gone back and improved on the original quick-and-dirty
>> MemoryContextStats mechanism.
> That code hasn't really gone anywhere since Neil tweaked the indentation
> two years ago. What sorts of improvements were you
On Fri, Dec 11, 2009 at 11:36 AM, Euler Taveira de Oliveira
wrote:
> Robert Haas escreveu:
>> On Thu, Dec 10, 2009 at 9:35 PM, Takahiro Itagaki
>> wrote:
>>> Anyway, a revised patch according to the comments is attached.
>>> The new text format is:
>>> Buffers: shared hit=675 read=968, temp read
Ashish wrote:
> I am thinking about starting with the following TODO item:
>
> --> Have EXPLAIN ANALYZE issue NOTICE messages when the estimated
> and actual row counts differ by a specified percentage.
>
> I picked this because it is somewhat related to query processing
> which is what I am most
I am thinking about starting with the following TODO item:
--> Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual
row counts differ by a specified percentage.
I picked this because it is somewhat related to query processing which is what I am
most interested in. It also
Bruce Momjian wrote:
> Well, the bottom line is that this effort should grow the development
> and user community of Postgres --- it if doesn't, it is a failure.
Really? Even if it only allows existing Postgres users and companies to
expand their use into higher security applications IMHO it's a
Ron Mayer wrote:
> Bruce Momjian wrote:
> > Well, the bottom line is that this effort should grow the development
> > and user community of Postgres --- it if doesn't, it is a failure.
>
> Really? Even if it only allows existing Postgres users and companies to
> expand their use into higher secur
On Fri, Dec 11, 2009 at 8:41 PM, Bruce Momjian wrote:
> I am not replying to many of these emails so I don't appear to be
> brow-beating (forcing) the community into accepting this features. I
> might be brow-beating the community, but I don't want to _appear_ to be
> brow-beating. ;-)
LOL. At
On Fri, Dec 11, 2009 at 3:50 PM, Tom Lane wrote:
> Zdenek Kotala writes:
>> Tom Lane píše v pá 11. 12. 2009 v 15:11 -0500:
>>> If we go this route it would be nice to think about making a facility
>>> that has some usefulness for non-DTrace platforms too.
>
>> Do you mean general facility for swi
Tom Lane wrote:
> Robert Haas writes:
> > Unlike Tom (I think), I do believe that there is demand (possibly only
> > from a limited number of people, but demand all the same) for this
> > feature.
>
> Please note that I do not think there is *zero* demand for the feature.
> There is obviously som
On Sun, Dec 6, 2009 at 11:29 PM, Greg Smith wrote:
> Magnus Hagander wrote:
>
> On Sun, Nov 29, 2009 at 13:05, Magnus Hagander wrote:
>
>
> I'll be happy to work on this to get it ready for commit, or do you
> want to do the updates?
>
>
> Here's a patch with my work so far. Major points missing
I'm not quite sure where we stand with these two patches. My
impression is that many of the outstanding TODO items in Hot Standby
have been fixed, and I'm not sure what remains. Streaming Replication
I think reviewing is not as far advanced, but I'm not sure. Any
chance that Hot Standby can get
Robert Haas wrote:
On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost wrote:
Hrm, I thought I had given a specific example. Didn't do a good job of
it, apparently. Let me try to be a bit more clear:
ALTER TABLE x OWNER TO y;
If given the table OID, there's a ton of information we can then pull
Robert Haas writes:
> What exactly do you mean by a SubOID? I'm not really following that part.
I assume he's talking about the object reference representation used in
pg_depend, which is actually class OID + object OID + sub-object ID.
The only object type that has sub-objects at the moment is
Stephen Frost wrote:
> Josh,
>
> * Joshua Brindle (met...@manicmethod.com) wrote:
>> Stephen Frost wrote:
>>> I do think that, technically, there's no reason we couldn't allow for
>>> multiple "only-more-restrictive" models to be enabled and built in a
>>> single binary for systems which support i
Stephen Frost wrote:
>> In my cosmetic preference, "ace_" is better than "ac_". The 'e' means
>> extendable, and "ace" feels like something cool. :-)
>
> No complaints here.. I just hope this doesn't end up being *exactly*
> the same as your original PGACE patches.. I'd feel terrible if we
> wer
On Fri, Dec 11, 2009 at 5:36 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost wrote:
>> > Does that help clarify my example case?
>>
>> That case doesn't seem terribly problematic to me. It seems clear
>> that we'll want to
I just did a round of integrating some of the big-picture feedback that
has shown up here since the meeting into
http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG ,
mainly supplementing the references in the "Works outside of SELinux"
section with the new suggested reading here s
Tom Lane wrote:
It's amazing to me that we've never
gone back and improved on the original quick-and-dirty
MemoryContextStats mechanism. I certainly find myself using that a
lot for issues like tracking down memory leaks.
That code hasn't really gone anywhere since Neil tweaked the indentation
Stephen Frost wrote:
I agree with this- one issue is, unfortunately, an overabundance from
KaiGai of "code-writing man-power". This is an odd situation for this
community, in general, so we're having a hard time coming to grasp with
it.
There are plenty of parallels to when Zdenek was writing a
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost wrote:
> > Does that help clarify my example case?
>
> That case doesn't seem terribly problematic to me. It seems clear
> that we'll want to pass some information about both x and y. What is
> less cl
* Robert Haas (robertmh...@gmail.com) wrote:
> If I don't tell
> you how to write the patch, you can't accuse me of moving the
> goalposts (of course I've now discovered the pitfalls of that approach
> as well...).
Indeed, we also yell and scream when we don't know which direction the
goalposts ar
On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost wrote:
> Hrm, I thought I had given a specific example. Didn't do a good job of
> it, apparently. Let me try to be a bit more clear:
>
> ALTER TABLE x OWNER TO y;
>
> If given the table OID, there's a ton of information we can then pull
> about the
On Fri, Dec 11, 2009 at 3:28 PM, Stephen Frost wrote:
> I sincerely hope that even if you suggest an approach down the road
> unrelated to this on some other patch you're reviewing, and then you see
> the results and say "whoah, that's horrible, and should never be
> committed", that you understan
Stephen (great name!),
* Stephen Smalley (s...@tycho.nsa.gov) wrote:
> Reference:
> http://www.usenix.org/event/sec02/wright.html
> http://lxr.linux.no/#linux+v2.6.32/include/linux/security.h
>
> The XACE framework for the X server is described by:
> http://www.x.org/releases/X11R7.5/doc/security
On Thursday 10 December 2009 21:47:18 KaiGai Kohei wrote:
> Greg Smith wrote:
> > It's funny; we started out this CommitFest with me scrambling to find
> > someone, anyone, willing to review the latest SE-PostgreSQL patch,
> > knowing it was a big job and few were likely to volunteer. Then
> > sch
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost wrote:
> > Second, the information we *don't* have from above is generally
> > information about what the requesting action is. For example, when
> > changing ownership of an object, we can't possibly us
I wrote:
> Takahiro Itagaki writes:
>> http://www.kernel.org/doc/man-pages/online/pages/man3/random_r.3.html
> It only says that you need those if you want an *independent* random
> sequence for each thread. pgbench never had that before and I doubt
> we need it now. In any case, the same page
Zdenek Kotala writes:
> Tom Lane pÃÅ¡e v pá 11. 12. 2009 v 15:11 -0500:
>> If we go this route it would be nice to think about making a facility
>> that has some usefulness for non-DTrace platforms too.
> Do you mean general facility for switching memory allocator?
No, I was thinking of some s
* Robert Haas (robertmh...@gmail.com) wrote:
> OK, it's clear that I've handled this badly. Sorry. My fear (however
> unjustified) was that someone would go and rewrite the patch based on
> an opinion that I express whether they agree with it or not.
That's always going to be a risk in an open-d
Takahiro Itagaki writes:
> While testing the pgbench setshell command patch with -j option,
> I found all threads use the same sequence of random value.
Were they actually threads, or were you testing the code while it had
the broken configure script that didn't set ENABLE_THREAD_SAFETY?
I think
On Fri, 2009-12-11 at 14:11 -0500, Stephen Frost wrote:
> All,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > If we design a security abstraction layer, the interfaces need to
> > really be abstraction boundaries. Passing the table OID and then also
> > the tablespace OID because PG DAC nee
I wrote:
> ... What I would have expected is crashes on the very
> similar updates to pgbench_branches, which is designed to be
> high-contention. It might be that there is some other effect going on
> here that explains why that wasn't happening. Need to go back and look
> more closely.
... and
Tom Lane píše v pá 11. 12. 2009 v 15:11 -0500:
> Zdenek Kotala writes:
> > I thought about it. I think we can use GUC variable (e.g. dtraced_alloc)
> > and hook switch pointers to dtraced AsetFunctions. The problem is how to
> > distribute to all backend.
>
> You set the GUC in postgresql.conf.
On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost wrote:
> Second, the information we *don't* have from above is generally
> information about what the requesting action is. For example, when
> changing ownership of an object, we can't possibly use introspection to
> find out the role which is on th
Josh,
* Joshua Brindle (met...@manicmethod.com) wrote:
> Stephen Frost wrote:
>> I do think that, technically, there's no reason we couldn't allow for
>> multiple "only-more-restrictive" models to be enabled and built in a
>> single binary for systems which support it. As such, I would make those
Zdenek Kotala writes:
> I thought about it. I think we can use GUC variable (e.g. dtraced_alloc)
> and hook switch pointers to dtraced AsetFunctions. The problem is how to
> distribute to all backend.
You set the GUC in postgresql.conf. No big deal.
If we go this route it would be nice to think
* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
> Yea I never asked Stephen if he goes by Stephen or Steve when I met him
> on Wednesday. I guess calling him Steve is me being a bit
> presumptuous :)
Oh, either is fine, tho people will probably follow a bit better if you
say "Stephen". As a rem
David,
* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
> So the document I read is linked below [1].
Great, thanks again.
[agree with all the rest]
> It is definitely good to have a second opinion on this since I've just
> only started reading the PCI compliance documents. I'm definitely not
Tom Lane píše v pá 11. 12. 2009 v 14:38 -0500:
> Robert Haas writes:
> > I thought we had an idea of using the AllocSet dispatch mechanism to
> > make this zero-overhead in the case where the probes are not enabled.
> > What happened to that notion?
>
> I must have missed that discussion, but +1
On Fri, Dec 11, 2009 at 1:52 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I actually have an idea how to solve the problem in this particular
>> case, but I'm reluctant to say what it is because I'm not sure if I'm
>> right, and at any rate *I don't want to write this
Tom Lane píše v pá 11. 12. 2009 v 13:56 -0500:
> Robert Haas writes:
> > As far as I am concerned that is way too much, particularly
> > considering that your test case isn't designed to be particularly
> > memory-allocation intensive, and if it is up to me I will reject this.
> > Even a quarter-
Greg Smith writes:
> It sounds like random pgbench run for a while would certainly expose the
> same thing you're concerned about eventually.
Yeah. Actually the odd thing about it is that the crash seemed to
invariably be on conflicting pgbench_accounts updates, which is a fairly
low-contention
Tom Lane wrote:
Also, the reason why Bruce's mistake exposed this is interesting.
Omitting the #define for ENABLE_THREAD_SAFETY does not actually break
"pgbench -j" at all -- it has a fallback strategy that uses multiple
subprocesses instead of multiple threads. However, it has only one
srandom(
Robert Haas writes:
> I thought we had an idea of using the AllocSet dispatch mechanism to
> make this zero-overhead in the case where the probes are not enabled.
> What happened to that notion?
I must have missed that discussion, but +1 --- should be possible to get
to zero-overhead-when-off tha
All,
* Robert Haas (robertmh...@gmail.com) wrote:
> If we design a security abstraction layer, the interfaces need to
> really be abstraction boundaries. Passing the table OID and then also
> the tablespace OID because PG DAC needs that to make its access
> control decision is crap.
Now, to ad
Robert Haas writes:
> As far as I am concerned that is way too much, particularly
> considering that your test case isn't designed to be particularly
> memory-allocation intensive, and if it is up to me I will reject this.
> Even a quarter-percent slowdown for a feature that will be used only
> b
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> I actually have an idea how to solve the problem in this particular
> case, but I'm reluctant to say what it is because I'm not sure if I'm
> right, and at any rate *I don't want to write this patch*.
As far as crap goes, I'd have to put th
Stephen Frost wrote:
KaiGai,
I do think that, technically, there's no reason we couldn't allow for
multiple "only-more-restrictive" models to be enabled and built in a
single binary for systems which support it. As such, I would make those
just "#if defined()" rather than "#elif". Let it be
On Fri, 2009-12-11 at 11:30 -0500, Robert Haas wrote:
[snip...]
>
> I'll stop here because I see that Stephen Frost has just sent an
> insightful email on this topic as well. Hmm, maybe that's the Steve
> you were referring to.
>
> ...Robert
>
Yea I never asked Stephen if he goes by Stephen or
On Fri, Dec 11, 2009 at 1:04 PM, Zdenek Kotala wrote:
> We know that performance impact is less then 1% probably less then 0.6%.
> The question is if it is acceptable or not. I personally think that it
> is acceptable. However if not, I will start work on backup solution with
> dtraced AllocSet an
I wrote:
> The crash is real --- I've replicated it here. Still trying to figure
> out what is the real cause.
Okay, I've sussed it. The crash itself is due to a memory management
mistake in the recently-rewritten EvalPlanQual code (pfree'ing a tuple
that we still have live Datum references to).
On Fri, 2009-12-11 at 01:19 +0200, Peter Eisentraut wrote:
> On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
> > There was considerable debate earlier about whether we wanted to treat
> > Python 3 as a separate PL so it could be available in parallel with
> > plpython 2, because of the user-leve
Robert Haas píše v pá 11. 12. 2009 v 12:55 -0500:
> On Fri, Dec 11, 2009 at 12:55 PM, Zdenek Kotala wrote:
> > Bernd Helmle píše v pá 11. 12. 2009 v 17:13 +0100:
> >>
> >> --On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
> >> wrote:
> >>
> >> >>
> >> >> without compiled probes: AVG(2531.68)
>
Robert Haas píše v čt 10. 12. 2009 v 23:55 -0500:
> On Wed, Dec 9, 2009 at 9:04 AM, Zdenek Kotala wrote:
> >
> > But in normal situation database does also other thing and palloc is
> > only one part of code path. It is why I run second test and use sun
> > studio profiling tools (collect/analyze
On Fri, Dec 11, 2009 at 12:55 PM, Zdenek Kotala wrote:
> Bernd Helmle píše v pá 11. 12. 2009 v 17:13 +0100:
>>
>> --On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
>> wrote:
>>
>> >>
>> >> without compiled probes: AVG(2531.68)
>> >> with compiled probes: AVG(2511.97)
>> >
>> > Were the probes
On Fri, 2009-12-11 at 11:36 -0500, Stephen Frost wrote:
[Snip...]
>
> > In addition, OS allows to choose one enhanced security at most eventually.
> >
> > In my image, the hook should be as:
> >
> > Value *
> > ac_database_create([arguments ...])
> > {
> > /*
> >* The default
Bernd Helmle píše v pá 11. 12. 2009 v 17:13 +0100:
>
> --On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
> wrote:
>
> >>
> >> without compiled probes: AVG(2531.68)
> >> with compiled probes: AVG(2511.97)
> >
> > Were the probes enabled?
>
> Hmm, they were just compiled in, i didn't anything
On Fri, 2009-12-11 at 11:16 -0500, Stephen Frost wrote:
> David,
>
> * David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
> > So I downloaded and read through the PCI DSS document (74 pages is
> > pretty light compared to NFSv4.1 hehe...) and There are several areas
> > there where I think strong acc
On Fri, 2009-12-11 at 11:28 -0500, Stephen Frost wrote:
[snip...]
> > The main concern I hear is that people are worried that this is an
> > SELinux specific design. I heard at the meeting on Wednesday that the
> > Trusted Extensions people looked at the framework and said it meets
> > their needs
On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley
wrote:
> The main concern I hear is that people are worried that this is an
> SELinux specific design. I heard at the meeting on Wednesday that the
> Trusted Extensions people looked at the framework and said it meets
> their needs as well. If tha
Bruce Momjian さんは書きました:
KaiGai Kohei wrote:
Takahiro Itagaki wrote:
KaiGai Kohei wrote:
Tom Lane wrote:
Takahiro Itagaki writes:
pg_largeobject should not be readable by the
public, since the catalog contains data in large objects of all users.
This is going to be a problem, becaus
KaiGai Kohei wrote:
> >>> We use "SELECT loid FROM pg_largeobject LIMIT 1" in pg_dump. We could
> >>> replace pg_largeobject_metadata instead if we try to fix only pg_dump,
> >>> but it's no wonder that any other user applications use such queries.
> >>> I think to allow reading loid is a balanced
Robert Haas escreveu:
> On Thu, Dec 10, 2009 at 9:35 PM, Takahiro Itagaki
> wrote:
>> Anyway, a revised patch according to the comments is attached.
>> The new text format is:
>> Buffers: shared hit=675 read=968, temp read=1443 written=1443
>>* Zero values are omitted. (Non-text formats could
* Robert Haas (robertmh...@gmail.com) wrote:
> I'll stop here because I see that Stephen Frost has just sent an
> insightful email on this topic as well. Hmm, maybe that's the Steve
> you were referring to.
I have doubts- but then I don't ever see my comments as insightful for
some reason. ;)
Greg,
* Greg Smith (g...@2ndquadrant.com) wrote:
> I think we need a two pronged attack on this issue. Eventually I think
> someone who wants this feature in there will need to sponsor someone
> (and not even necessarily a coder) to do a sizable round of plain old
> wording cleanup on the c
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> As Rober Haas already suggested in another message, my patch in the last
> commit fest is too large. It tried to rework anything in a single patch.
> The "per-object-type" basis make sense for me.
Agreed.
> In my cosmetic preference, "ace_" i
Joshua Brindle wrote:
Greg Smith wrote:
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed
On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley
wrote:
> On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote:
>> 2009/12/11 KaiGai Kohei :
>> > It tried to provide a set of comprehensive entry points to replace existing
>> > PG checks at once.
>> > However, the SE-PgSQL/Lite patch covers acces
* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
> On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote:
> > I think that we should try to move the PG default checks inside the
> > hook functions. If we can't do that cleanly, it's a good sign that
> > the hook functions are not correctly placed t
David,
* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
> So I downloaded and read through the PCI DSS document (74 pages is
> pretty light compared to NFSv4.1 hehe...) and There are several areas
> there where I think strong access controls in the database will not only
> fulfill the requirement
--On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
wrote:
without compiled probes: AVG(2531.68)
with compiled probes: AVG(2511.97)
Were the probes enabled?
Hmm, they were just compiled in, i didn't anything to instrument them with
dtrace.
I've just started a pgbench/dtrace run wit
KaiGai Kohei wrote:
> Takahiro Itagaki wrote:
> > KaiGai Kohei wrote:
> >
> >> Tom Lane wrote:
> >>> Takahiro Itagaki writes:
> pg_largeobject should not be readable by the
> public, since the catalog contains data in large objects of all users.
> >>> This is going to be a proble
On Fri, 2009-12-11 at 08:56 -0500, Stephen Frost wrote:
[snip...]
> I do assume we're going to do row level security, but I do not feel that
> we need to particularly put one in front of the other. I also feel that
> SEPG will be valuable even without row-level security. One of the
> realms that
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Dec 11, 2009 at 05:45, Tom Lane wrote:
> > It's been perfectly clear since day one, and was reiterated as recently
> > as today
> > http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
> > that what the securit
Greg Smith wrote:
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group o
On 12/11/09, Tom Lane wrote:
> Alvaro Herrera writes:
> > Yes, but what if you test with the broken pgbench? As Tom says, it
> > should not be able to crash the backend no matter what it does.
>
>
> The crash is real --- I've replicated it here. Still trying to figure
> out what is the real
On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote:
> 2009/12/11 KaiGai Kohei :
> > It tried to provide a set of comprehensive entry points to replace existing
> > PG checks at once.
> > However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
> > tables and columns. Is it neces
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> (1) Whether the framework should host the default PG model, not only
>> enhanced security features, or not?
>> This patch tried to host both of the default PG model and SELinux.
>> But, the default PG model
Alvaro Herrera writes:
> Yes, but what if you test with the broken pgbench? As Tom says, it
> should not be able to crash the backend no matter what it does.
The crash is real --- I've replicated it here. Still trying to figure
out what is the real cause.
regards, tom l
Robert Haas wrote:
One comment I have in general about this process is that I think it
would enormously reduce the level of pain associated with making these
kinds of changes if we could get patches that were not full of minor
issues that need to be cleaned up (like comments not properly
adjusted
On Fri, 2009-12-11 at 09:20 -0500, Robert Haas wrote:
> On Fri, Dec 11, 2009 at 4:31 AM, Magnus Hagander wrote:
> > On Fri, Dec 11, 2009 at 05:45, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane wrote:
> My guess is that a credible SEPostgres offeri
Stephen Frost wrote:
Tom,
The
proposals to make SEPostgres drive regular SQL permissions never came
out of anyone from that side, they were proposed by PG people looking
for a manageable first step.
I do not believe this to be accurate. Josh, were you able to find any
public documentation
Jaime Casanova wrote:
> On Thu, Dec 10, 2009 at 11:33 PM, Jaime Casanova
> wrote:
> > On Thu, Dec 10, 2009 at 11:22 PM, Tom Lane wrote:
> >>
> >> My bet is that the real problem was a build inconsistency in
> >> the backend. Does "make distclean" and rebuild make it go away?
> >>
> >
> > actuall
2009/12/11 KaiGai Kohei :
> It tried to provide a set of comprehensive entry points to replace existing
> PG checks at once.
> However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
> tables and columns. Is it necessary to be comprehensive from the beginning?
> It might be too a
Bernd Helmle escribió:
> I repeated the pgbench runs per Greg's advice (see upthread) and it
> seems there is actually a small slowdown which supports this
> argument, unfortunately. After repeating the pgbench runs with and
> without the new probes (note: i've used the new version of the
> patch,
--On 10. Dezember 2009 23:55:49 -0500 Robert Haas
wrote:
If there's some real-world test where this probe costs 0.3%-0.4%, I
think that is sufficient grounds for rejecting this patch. I
understand the desire of people to be able to use dtrace, but our
performance is too hard-won for me to
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> (1) Whether the framework should host the default PG model, not only
> enhanced security features, or not?
> This patch tried to host both of the default PG model and SELinux.
> But, the default PG model does not have same origin with
On Fri, Dec 11, 2009 at 4:31 AM, Magnus Hagander wrote:
> On Fri, Dec 11, 2009 at 05:45, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane wrote:
My guess is that a credible SEPostgres offering will require a long-term
amount of work at least equal t
1 - 100 of 107 matches
Mail list logo
