Simon Riggs writes:
> I fail to see how rejecting unreviewed patches provides benefit for
> users, developers or sponsors.
Nobody has suggested rejecting either sync replication or standby database.
The debate here is over whether to commit into 8.4 or into 8.5.
Put another way, the choice he
Heikki Linnakangas writes:
> Not really, except maybe started 6 months too late. Big patches simply take a
> long time to mature.
>
> Looking back at the timeline for hot standby, it doesn't look unreasonable at
> all:
>
> September: First discussion about the user-visible behavior, transaction
>
Gregory Stark writes:
> Put another way, the choice here is whether to have a half-baked delayed 8.4
> release in 6 months or a polished on-time 8.5 release in 12 months. Either way
> the feature ships and on a not terribly different timeline either.
This is pretty much exactly how I see it. *Ho
Tom Lane writes:
> Gregory Stark writes:
>> Put another way, the choice here is whether to have a half-baked delayed 8.4
>> release in 6 months or a polished on-time 8.5 release in 12 months. Either
>> way
>> the feature ships and on a not terribly different timeline either.
>
> This is pretty
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
> Gregory Stark writes:
>> Put another way, the choice here is whether to have a half-baked delayed 8.4
>> release in 6 months or a polished on-time 8.5 release in 12 months. Either
>> way
>> the feature ships and on a not terribly different timel
On 1/26/09, Tom Lane wrote:
> Gregory Stark writes:
> > Put another way, the choice here is whether to have a half-baked delayed
> 8.4
> > release in 6 months or a polished on-time 8.5 release in 12 months. Either
> way
> > the feature ships and on a not terribly different timeline either.
>
On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure wrote:
> What about a compromise solution: release 8.4 now, then focus on
> wrapping up the big ticket items that didn't make it into 8.4 into a
> quick (as possible) 8.5 release. This means no fests.
That would depend on timing then. Trying to
Dave Page writes:
> On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
>> This is pretty much exactly how I see it. *Hot standby is not ready*,
> So can you give us an idea of what parts of the code are in need of
> rethinking etc? I assume you've looked at it now if you can estimate
> it's going
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
>>> This is pretty much exactly how I see it. *Hot standby is not ready*,
>
>> So can you give us an idea of what parts of the code are in need of
>> rethinking etc? I assume
"Jonah H. Harris" writes:
> On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure wrote:
>> What about a compromise solution: release 8.4 now, then focus on
>> wrapping up the big ticket items that didn't make it into 8.4 into a
>> quick (as possible) 8.5 release. This means no fests.
> That would d
On 1/26/09, Jonah H. Harris wrote:
> On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure wrote:
> > What about a compromise solution: release 8.4 now, then focus on
> > wrapping up the big ticket items that didn't make it into 8.4 into a
> > quick (as possible) 8.5 release. This means no fests.
>
>
On Mon, Jan 26, 2009 at 11:33 AM, Tom Lane wrote:
> > That would depend on timing then. Trying to get people to upgrade to 8.4
> is
> > going to be difficult if they're waiting on Hot Standby, which means less
> > in-the-field testing of the 8.4 code base until the 8.5 release.
>
> [ deja vu...
Tom Lane writes:
> Dave Page writes:
>> On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
>>> This is pretty much exactly how I see it. *Hot standby is not ready*,
>
>> So can you give us an idea of what parts of the code are in need of
>> rethinking etc? I assume you've looked at it now if you
Dave Page wrote:
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane wrote:
Dave Page writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
This is pretty much exactly how I see it. *Hot standby is not ready*,
So can you give us an idea of what parts of the code are in need of
rethinking etc? I
Dave Page writes:
> On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane wrote:
>> ... (If you expect me to sign off on it you can
>> figure it'll be a couple of months even for that to happen...)
> Well there is one of the problems imho - the project is getting too
> big and the patches are getting too c
On Mon, Jan 26, 2009 at 11:44 AM, Jonah H. Harris
wrote:
> On Mon, Jan 26, 2009 at 11:33 AM, Tom Lane wrote:
>>
>> > That would depend on timing then. Trying to get people to upgrade to
>> > 8.4 is
>> > going to be difficult if they're waiting on Hot Standby, which means
>> > less
>> > in-the-fi
> I think that's baked in the cards no matter what. IMO, the issue is
> that code to review is building up faster than it is getting reviewed,
> so maybe a festless release is nesessary to flush out the difference
> (along with the other held over patches from 8.4).
How is that going to help? Pe
Robert Haas wrote:
The other thing going on here is that HS is extremely important to the
project. If it was up to me, 100% effort would be geared to getting
it out as quickly as possible. I'm just looking for a way to get HS
in the hands of people as quickly as possible that is fair to
everybo
On Mon, 2009-01-26 at 12:47 -0500, Robert Haas wrote:
> How is that going to help? People will still write new code in the
> meanwhile and some of it may be better or more important than the
> stuff that doesn't get committed to 8.4. Artificially saying that
> nothing will be allowed for 8.5 tha
All,
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world. I'm
convinced that if we took a staw poll, 80% of our users would be in
favor of waiting for HS. This one feature will make more of a
difference in the number of PG users
On Mon, 2009-01-26 at 11:36 -0800, Josh Berkus wrote:
> All,
>
> So, some feedback to make this decision more difficult:
>
> Users: care about HS more than anything else in the world. I'm
> convinced that if we took a staw poll, 80% of our users would be in
> favor of waiting for HS. This one
On 1/26/09, Josh Berkus wrote:
> All,
>
> So, some feedback to make this decision more difficult:
>
> Users: care about HS more than anything else in the world. I'm convinced
> that if we took a staw poll, 80% of our users would be in favor of waiting
> for HS. This one feature will make more
Merlin,
Not completely. HS is in much better shape than win32 was when it was
pulled from 7.4...the build system wasn't even in place yet nor any of
the major challenges solved (like fork/exec).
HS is working very well (Simon's ongoing work aside). I am pretty
confident based on my personal t
On Mon, Jan 26, 2009 at 2:36 PM, Josh Berkus wrote:
> All,
>
> So, some feedback to make this decision more difficult:
>
> Users: care about HS more than anything else in the world. I'm convinced
> that if we took a staw poll, 80% of our users would be in favor of waiting
> for HS. This one feat
All,
1) having the last CF on Nov. 1 was a mistake. That put us square in the
path of the US & Christian holidays during the critical integration phase ..
which means we haven't really had 3 months of integration, we've had *two*.
Actually, I'm thinking about this again, and made a mistake ab
Josh Berkus writes:
> So, some feedback to make this decision more difficult:
> Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users who
would like an in-core replication solution, but HS by itself is not that
--- you also
Merlin Moncure writes:
> HS is working very well (Simon's ongoing work aside). I am pretty
> confident based on my personal testing that it would represent the
> project well if committed today.
I think a lot of people weren't aware there was anybody testing this patch
other than Simon and Hei
On 1/26/09, Josh Berkus wrote:
> All,
>
>>> 1) having the last CF on Nov. 1 was a mistake. That put us square in the
>>> path of the US & Christian holidays during the critical integration phase
>>> ..
>>> which means we haven't really had 3 months of integration, we've had
>>> *two*.
>
> Actuall
On 1/26/09, Gregory Stark wrote:
>
> Merlin Moncure writes:
>
> > HS is working very well (Simon's ongoing work aside). I am pretty
> > confident based on my personal testing that it would represent the
> > project well if committed today.
>
>
> I think a lot of people weren't aware there wa
Gregory Stark writes:
> Here's a thought experiment. If it was committable *today* would we be
> willing to go with it and plan to release with it? Assume that it
> would *still* mean a longer beta process, so it would still mean
> releasing in, say April instead of February or March.
"April inst
On Mon, 2009-01-26 at 20:12 +, Gregory Stark wrote:
> Merlin Moncure writes:
>
> > HS is working very well (Simon's ongoing work aside). I am pretty
> > confident based on my personal testing that it would represent the
> > project well if committed today.
>
> I think a lot of people weren
Tom Lane wrote:
Josh Berkus writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users who
would like an in-core replication solution, but HS by itself is not
On Mon, 2009-01-26 at 15:47 -0500, Merlin Moncure wrote:
> I'd also like to see Simon and or
> Heikki make a strong statement on where things stand _right now_ (not
> in two weeks) :-)
Well, we just found 2 bugs over the weekend, one of which is a
regression from refactoring.
The second bug is
On Mon, 2009-01-26 at 15:49 -0500, Tom Lane wrote:
> The problem is that it's not ready and no one is very sure about when
> it will be.
With respect, I've done more than any other developer has done to give
you and the community full information on the patch as it develops. I'm
sorry you don't
Josh Berkus wrote:
All,
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world. I'm
convinced that if we took a staw poll, 80% of our users would be in
favor of waiting for HS. This one feature will make more of a
difference in the
On Monday 26 January 2009 2:12:02 pm Tom Lane wrote:
> Josh Berkus writes:
> > So, some feedback to make this decision more difficult:
> >
> > Users: care about HS more than anything else in the world.
>
> I don't think this is correct. There are certainly a lot of users who
> would like an in-co
On 1/26/09 4:28 PM, "Joshua Brindle" wrote:
> Tom Lane wrote:
>> Josh Berkus writes:
>>> SE-Linux: this patch has effectively been in development for 2 years
>>> ourside the core process before putting it in; the forked SEPostgres is
>>> in use in production. KaiGai has been available for 20
Gregory Stark wrote:
>
> I think a lot of people weren't aware there was anybody testing this patch
> other than Simon and Heikki -- I wasn't until just today. I wonder how many
> more people are trying it out?
I've been running the patch (I think since Jan 5) on a couple dev instances
that were
Gregory Stark wrote:
> I think a lot of people weren't aware there was anybody testing this patch
> ...I wonder how many more people are trying it out?
I think I have an idea to improve this aspect for future commit fests.
For a long time at each of my workplaces I've been running a development
i
Ron Mayer writes:
> I realize in the current system (emailed patches), this would be a horrible
> pain to maintain such a branch; but perhaps some of the burden could be
> pushed down to the patch submitters (asking them to merge their own changes
> into this merged branch).
I've considered
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Josh Berkus writes:
> > Users: care about HS more than anything else in the world.
>
> I don't think this is correct. There are certainly a lot of users who
> would like an in-core replication solution, but HS by itself is not that
> --- you also need (ne
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> The problem, in words of one syllable, is that we are not sure we want
>> it. Do you see a user community clamoring for SEPostgres, or a hacker
>> community that is willing or able to maintain it?
> No, it doesn't have as large a
Tom Lane wrote:
> The problem, in words of one syllable, is that we are not sure we want
> it. Do you see a user community clamoring for SEPostgres, or a hacker
This is a chicken-and-egg type of problem.
Security-conscious users, applications, hackers, and customers will
flock towards whichever
On Monday 26 January 2009 6:31:48 pm Ron Mayer wrote:
> Tom Lane wrote:
[...snip...]
> > The second problem is that we're not sure it's really the right thing,
> > because we have no one who is competent to review the design from a
> > security standpoint. But unless we get past the first problem
On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
> Then why has *nobody* stepped up to review the design, much less the
> whole patch? The plain truth is that no one appears to care enough to
> expend any real effort. But this patch is far too large and invasive
> to accept on the basis that o
Ron Mayer writes:
> Tom Lane wrote:
>> The second problem is that we're not sure it's really the right thing,
>> because we have no one who is competent to review the design from a
>> security standpoint.
> Are we underestimating Kaigai Kohei?
Perhaps he walks on water, but still I'd like to hav
Tom Lane wrote:
> Ron Mayer writes:
>> Are we underestimating Kaigai Kohei?
> Perhaps he walks on water, but still I'd like to have more than one
> person who has confidence that this design and implementation are correct.
Totally fair. I know I'm totally unqualified to review his buoyancy on
wa
"Joshua D. Drake" writes:
> On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
>> Then why has *nobody* stepped up to review the design, much less the
>> whole patch?
> It was only today that I saw an announcement go out to our announce list
> to try and get people to pop their heads up and help.
Tom Lane wrote:
> Hmm, you think selinux people read pgsql-announce? But seriously,
> we *have* been trying to get people's attention for this patch, both
> inside and outside the postgres community, for well over a year now.
> The lack of response has been depressing and (IMHO) telling. Nowhere
* Ron Mayer (rm...@cheapcomplexdevices.com) wrote:
> Tom Lane wrote:
> > Hmm, you think selinux people read pgsql-announce? But seriously,
> > we *have* been trying to get people's attention for this patch, both
> > inside and outside the postgres community, for well over a year now.
> > The lack
On Mon, 2009-01-26 at 20:28 -0500, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
> >> Then why has *nobody* stepped up to review the design, much less the
> >> whole patch?
>
> > It was only today that I saw an announcement go out to our announ
Tom Lane wrote:
Ron Mayer writes:
Tom Lane wrote:
The second problem is that we're not sure it's really the right thing,
because we have no one who is competent to review the design from a
security standpoint.
Are we underestimating Kaigai Kohei?
Perhaps he walks on water, but still I'd l
Stephen Frost writes:
> * Ron Mayer (rm...@cheapcomplexdevices.com) wrote:
>> Ah! Then yes, that does say something about the lack of interest.
>> It wasn't obvious to me that people were reaching out beyond these lists.
> Where were we reaching outside the postgres community..?
Well, I've been
Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> The problem, in words of one syllable, is that we are not sure we want
>>> it. Do you see a user community clamoring for SEPostgres, or a hacker
>>> community that is willing or able to maintain it?
>
>> No, it
Jaime Casanova wrote:
SE-Linux: this patch has effectively been in development for 2 years
ourside the core process before putting it in; the forked SEPostgres is in
use in production. KaiGai has been available for 20 hours a week (or more)
to troubleshoot issues and change APIs. I really don't
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, I've been trying to get Red Hat to interest their NSA contacts in
> it, and Bruce and Josh B have been making efforts via EDB and Sun that
> I don't have details about, but nothing much has come of any of that.
It's certainly frustrating to hear that
Joshua Brindle wrote:
> While we haven't been able to analyze the patches directly to
> determine whether the security goals are indeed being met we
> have had much discussion and eventually community agreement on
> the security model being implemented. This happened years ago
> and has since been
Tom Lane wrote:
> Ron Mayer writes:
>> Tom Lane wrote:
>>> The second problem is that we're not sure it's really the right thing,
>>> because we have no one who is competent to review the design from a
>>> security standpoint.
>
>> Are we underestimating Kaigai Kohei?
>
> Perhaps he walks on wat
On Tue, 2009-01-27 at 12:30 +0900, KaiGai Kohei wrote:
>
> BTW, I have not walked on water yet.
>
I have but I always end up wet. :)
Joshua D. Drake
> Thanks,
--
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.command
> Jonah H. Harris; Gregory Stark; Simon Riggs; Bruce Momjian; Bernd
> Helmle; Peter Eisentraut; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 8.4 release planning
>
> On Tue, 2009-01-27 at 12:30 +0900, KaiGai Kohei wrote:
>
> >
> > BTW, I have not walked on wa
. Harris; Gregory Stark; Simon Riggs; Bruce Momjian; Bernd
Helmle; Peter Eisentraut; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 8.4 release planning
On Tue, 2009-01-27 at 12:30 +0900, KaiGai Kohei wrote:
BTW, I have not walked on water yet.
I have but I always end up wet. :)
I find that
Joshua Brindle writes:
> http://marc.info/?l=selinux&m=115762285013528&w=2
> Is the original discussion thread for the security model used in the
> sepostgresql work. Hopefully you'll see some of the evidence you speak of
> there.
Thanks for the link. I took a look through that thread and saw
OK, time for me to chime in.
I think the outstanding commit-fest items can be broken down into four
sections:
o Log streaming
o Hot standby
o SE-PostgreSQL
o Others
I think we all agree that log streaming is not ready for 8.4, and that
delaying for this featur
All,
FWIW, I'll comment that what we're seeing here is nothing new. We have:
--One invasive patch which everybody (myself included) procrastinated on
reviewing even though we got it early, and:
--One "must have" big complex patch which arrived very late in the
development cycle.
These are
Josh Berkus writes:
> FWIW, I'll comment that what we're seeing here is nothing new.
Certainly the Hot Standby situation is the same old song, different verse.
(I'm personally of the opinion that the project has usually been better
served when we decided not to postpone a release to wait for a s
On Mon, 2009-01-26 at 23:39 -0500, Tom Lane wrote:
> Josh Berkus writes:
> > FWIW, I'll comment that what we're seeing here is nothing new.
> Meanwhile it's emerging that the selinux people don't feel qualified to
> review it either. I'm not quite sure what to do about that. But "throw
> it in
> SEPostgres seems qualitatively different to me, though. I think PG
> people have avoided reviewing it because (a) they weren't interested in
> it and (b) they knew they were unqualified to review it.
I think that you are off-base here. As I've pointed out previously,
nobody was ever ASSIGNED t
Robert,
The reviewing that happened during this CommitFest did not happen on
the basis of who was interested in which patches. There was a bit of
that, but for the most part people reviewed the patches that they were
asked to review. I assumed (am I the only one?) that the REASON why
we were n
>> The reviewing that happened during this CommitFest did not happen on
>> the basis of who was interested in which patches. There was a bit of
>> that, but for the most part people reviewed the patches that they were
>> asked to review. I assumed (am I the only one?) that the REASON why
>> we we
2009/1/27 Joshua D. Drake :
> On Mon, 2009-01-26 at 23:39 -0500, Tom Lane wrote:
>> Josh Berkus writes:
>> > FWIW, I'll comment that what we're seeing here is nothing new.
>
>> Meanwhile it's emerging that the selinux people don't feel qualified to
>> review it either. I'm not quite sure what to
On Mon, Jan 26, 2009 at 6:07 PM, Gregory Stark wrote:
>> I realize in the current system (emailed patches), this would be a horrible
>> pain to maintain such a branch; but perhaps some of the burden could be
>> pushed down to the patch submitters (asking them to merge their own changes
>> into thi
On Tue, Jan 27, 2009 at 12:40 AM, Pavel Stehule wrote:
> so it could be released. 8.5 should be implemented in shorted
> cycle - only one commitfest, that is enough (+3 month) for well
> completing SE and replication patches.
we tried this before (8.2 to 8.3 i think), the idea was that the next
r
2009/1/27 Jaime Casanova :
> On Tue, Jan 27, 2009 at 12:40 AM, Pavel Stehule
> wrote:
>> so it could be released. 8.5 should be implemented in shorted
>> cycle - only one commitfest, that is enough (+3 month) for well
>> completing SE and replication patches.
>
> we tried this before (8.2 to 8.3
Pavel Stehule wrote:
2009/1/27 Jaime Casanova :
On Tue, Jan 27, 2009 at 12:40 AM, Pavel Stehule wrote:
so it could be released. 8.5 should be implemented in shorted
cycle - only one commitfest, that is enough (+3 month) for well
completing SE and replication patches.
we tried this before (8.2
Sorry for long description.
Tom Lane wrote:
> Joshua Brindle writes:
>> http://marc.info/?l=selinux&m=115762285013528&w=2
>> Is the original discussion thread for the security model used in the
>> sepostgresql work. Hopefully you'll see some of the evidence you speak of
>> there.
>
> Thanks fo
Bruce Momjian wrote:
OK, time for me to chime in.
I think the outstanding commit-fest items can be broken down into four
sections:
o Log streaming
o Hot standby
o SE-PostgreSQL
o Others
- snip -
SE-PostgreSQL has been in steady development for a year so
Josh Berkus writes:
> The idea behind having new reviewers take on all the small patches, was,
> of course, to give the main committers more time with patches like
> SEPostgres. It worked with other stuff (like Windowing and CTE).
Huh? There were certainly non-committer reviewers for the wind
On Mon, Jan 26, 2009 at 8:12 PM, Tom Lane wrote:
> Josh Berkus writes:
>> So, some feedback to make this decision more difficult:
>
>> Users: care about HS more than anything else in the world.
>
> I don't think this is correct. There are certainly a lot of users who
> would like an in-core repl
On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
> Then why has *nobody* stepped up to review the design, much less the
> whole patch? The plain truth is that no one appears to care enough to
> expend any real effort.
I've spent some time looking at it and have made all the comments I
wished
Dave Page wrote:
On Mon, Jan 26, 2009 at 8:12 PM, Tom Lane wrote:
Josh Berkus writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users wh
On Jan 27, 2009, at 2:41 AM, Mark Kirkwood wrote:
Dave Page wrote:
On Mon, Jan 26, 2009 at 8:12 PM, Tom Lane wrote:
Josh Berkus writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> SEPostgres seems qualitatively different to me, though. I think PG
> people have avoided reviewing it because (a) they weren't interested in
> it and (b) they knew they were unqualified to review it.
>
> Meanwhile it's emerging that the selinux people don'
Simon Riggs wrote:
> On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
>
>> Then why has *nobody* stepped up to review the design, much less the
>> whole patch? The plain truth is that no one appears to care enough to
>> expend any real effort.
>
> I've spent some time looking at it and have ma
On Tuesday 27 January 2009 00:42:32 Ron Mayer wrote:
> If it were just as easy for us to pull from a
> "all 'pending-patches' for-commit-fest-nov that pass regression tests"
> branch, I'd happily pull from that instead.
Considering that most patches don't come with regression tests, this would
Bruce Momjian píše v po 26. 01. 2009 v 23:02 -0500:
> OK, time for me to chime in.
>
> I think the outstanding commit-fest items can be broken down into four
> sections:
>
> o Log streaming
> o Hot standby
> o SE-PostgreSQL
> o Others
You omit pg_upgrade. Does it mea
On Tuesday 27 January 2009 02:21:41 Tom Lane wrote:
> Then why has *nobody* stepped up to review the design, much less the
> whole patch? The plain truth is that no one appears to care enough to
> expend any real effort. But this patch is far too large and invasive
> to accept on the basis that o
Simon Riggs wrote:
> The process works like this: software gets developed, then it gets
> certified. If its not certified, then Undercover Elephant will not be
> used by the secret people. We can't answer the "will it be certified?"
> question objectively yet. If we have someone willing to write th
Peter Eisentraut wrote:
> On Tuesday 27 January 2009 00:42:32 Ron Mayer wrote:
>> If it were just as easy for us to pull from a
>> "all 'pending-patches' for-commit-fest-nov that pass regression tests"
>> branch, I'd happily pull from that instead.
>
> Considering that most patches don't come wi
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
> As one of the earlier reviewers, I think the design is OK, but the way the
> implementation is presented was not acceptable, and very little has been
> accomplished in terms of reacting to our comments. For example, where is the
> SQL row se
On Tue, Jan 27, 2009 at 06:20:41AM -0800, Ron Mayer wrote:
> For what it's worth, we can see that there are indeed
> Postgres forks on the Common Criteria certified list.
>
> http://www.commoncriteriaportal.org/products_DB.html
> PostgreSQL Certified Version V8.1.5 for Linux
> Manufacture
Tom Lane wrote:
Joshua Brindle writes:
http://marc.info/?l=selinux&m=115762285013528&w=2
Is the original discussion thread for the security model used in the
sepostgresql work. Hopefully you'll see some of the evidence you speak of there.
Thanks for the link. I took a look through that thre
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
SEPostgres seems qualitatively different to me, though. I think PG
people have avoided reviewing it because (a) they weren't interested in
it and (b) they knew they were unqualified to review it.
Meanwhile it's emerging that the selin
On Tue, 2009-01-27 at 06:40 +0100, Pavel Stehule wrote:
> > 8.4-stable
> > 8.4-experimental
> >
> > stable is everything that stable is. PostgreSQL at its best.
> >
>
> I dislike this idea - it's same like short processed 8.5 -
Actually it isn't because we wouldn't accept features into
8.4-expe
On Tue, 2009-01-27 at 00:58 -0500, Jaime Casanova wrote:
> On Tue, Jan 27, 2009 at 12:40 AM, Pavel Stehule
> wrote:
> > so it could be released. 8.5 should be implemented in shorted
> > cycle - only one commitfest, that is enough (+3 month) for well
> > completing SE and replication patches.
>
>
On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote:
> Josh Berkus writes:
> > So, some feedback to make this decision more difficult:
>
> > Users: care about HS more than anything else in the world.
>
> I don't think this is correct.
I do.
People literally grab my shoulder and ask when w
Dave Page writes:
> On Mon, Jan 26, 2009 at 8:12 PM, Tom Lane wrote:
>> Josh Berkus writes:
>>> Users: care about HS more than anything else in the world.
>>
>> I don't think this is correct. There are certainly a lot of users who
>> would like an in-core replication solution, but HS by itself
On Mon, 2009-01-26 at 22:55 -0500, Tom Lane wrote:
> Silently filtering out rows according to an arbitrary security policy
> can break a bunch of fundamental SQL semantics, the most obvious being
> foreign key constraints
That was exactly my reaction when I read the way it worked and I was
ready
On Tue, 2009-01-27 at 10:51 -0500, Tom Lane wrote:
> Without an integrated and fairly high-performance log
> shipping capability, they are not going to find HS very compelling.
> Claiming otherwise is just wishful thinking.
What HS will give us is same or better than the equivalent feature in
lat
Simon Riggs writes:
> On Mon, 2009-01-26 at 22:55 -0500, Tom Lane wrote:
>> Silently filtering out rows according to an arbitrary security policy
>> can break a bunch of fundamental SQL semantics, the most obvious being
>> foreign key constraints
> That was exactly my reaction when I read the way
> Yeah, people like certification, but they also like products that work.
> Did you stop reading before getting to my non-security-based complaints?
I read them, but I suspect they are issues that can be addressed. How
would any of this affect join removal, anyway? At most it would
affect join r
1 - 100 of 257 matches
Mail list logo
