Tom,
The other thing that is commonly thought of as email integration
is the ability to generate notification email, which AFAIK the wiki
does have
Um, no. It doesn't, and really can't.
Notifying everyone who's updated the page isn't terribly useful.
--Josh
--
Sent via pgsql-hackers
Josh Berkus j...@agliodbs.com writes:
Tom,
The other thing that is commonly thought of as email integration
is the ability to generate notification email, which AFAIK the wiki
does have
Um, no. It doesn't, and really can't.
Oh. What's that watch this page option do, then?
Josh Berkus wrote:
Stephen Frost wrote:
* Gregory Stark (st...@enterprisedb.com) wrote:
It does seem weird to simply omit records rather than throw an error and
require the user to use a where clause, even if it's something like
WHERE
pg_accessible(tab).
The idea is for the level of
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Stephen Frost wrote:
It does seem weird to simply omit records rather than throw an error
The presumption is that if you know the data exists but can't access it
directly, you'll use indirect methods to derive what it is. But if you
Tom,
Oh. What's that watch this page option do, then?
Notifies you when anyone makes any change of any kind to *any* patch (or
piece of text, for that matter) in the commitfest. Including something
like changing the number of patches assigned to an RRR.
My inability to systematically
Josh,
We do not consider that a short coming, anyone who needs to hide
existence of files needs to set up their directory structure to disallow
read/search/create on the directories they aren't allowed to discover
filenames in. Polyinstanciation can also address this issue.
Hmmm. Why try
Josh Berkus wrote:
Josh,
We do not consider that a short coming, anyone who needs to hide
existence of files needs to set up their directory structure to
disallow read/search/create on the directories they aren't allowed to
discover filenames in. Polyinstanciation can also address this
Josh Berkus j...@agliodbs.com writes:
Tom,
Oh. What's that watch this page option do, then?
Notifies you when anyone makes any change of any kind to *any* patch (or
piece of text, for that matter) in the commitfest. Including something
like changing the number of patches assigned to an
On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 27, 2009 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It would prevent us from making optimizations that assume foreign key
constraints hold; which is a performance
Andrew,
* Andrew Sullivan (a...@crankycanuck.ca) wrote:
Throwing an error would entail a side-channel leak that would not be
acceptable to the security community, I bet. That said, I have
reservations, along the lines of Peter E's, that the early
design-level objections to the approach were
Joshua Brindle met...@manicmethod.com writes:
Tom Lane wrote:
Right, which is why it's bad for something like a foreign key constraint
to expose the fact that the row does exist after all.
Once again, this is not an issue for us.
Yes it is an issue; claiming it isn't doesn't make it so. You
* Tom Lane (t...@sss.pgh.pa.us) wrote:
This seems to me to be exactly parallel to deciding that SELinux should
control only table/column permissions within SQL; an approach that would
be enormously less controversial, less expensive, and more reliable than
what SEPostgres tries to do.
While
Stephen Frost wrote:
* Gregory Stark (st...@enterprisedb.com) wrote:
It does seem weird to simply omit records rather than throw an error and
require the user to use a where clause, even if it's something like WHERE
pg_accessible(tab).
It is weird from an SQL perspective, I agree with you
Tom Lane wrote:
Joshua Brindle met...@manicmethod.com writes:
Tom Lane wrote:
Right, which is why it's bad for something like a foreign key constraint
to expose the fact that the row does exist after all.
Once again, this is not an issue for us.
Yes it is an issue; claiming it isn't
On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote:
Josh Berkus wrote:
Josh,
We do not consider that a short coming, anyone who needs to hide
existence of files needs to set up their directory structure to
disallow read/search/create on the directories they aren't allowed to
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
This seems to me to be exactly parallel to deciding that SELinux should
control only table/column permissions within SQL; an approach that would
be enormously less controversial, less expensive, and more reliable than
what SEPostgres
Tom Lane escribió:
Josh Berkus j...@agliodbs.com writes:
Tom,
The other thing that is commonly thought of as email integration
is the ability to generate notification email, which AFAIK the wiki
does have
Um, no. It doesn't, and really can't.
Oh. What's that watch this page
Ron Mayer wrote:
Stephen Frost wrote:
* Gregory Stark (st...@enterprisedb.com) wrote:
It does seem weird to simply omit records rather than throw an error and
require the user to use a where clause, even if it's something like WHERE
pg_accessible(tab).
It is weird from an SQL perspective, I
On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joshua Brindle met...@manicmethod.com writes:
Tom Lane wrote:
Right, which is why it's bad for something like a foreign key constraint
to expose the fact that the row does exist after all.
Once again, this is not an issue
On Tue, 2009-01-27 at 14:18 -0500, Tom Lane wrote:
Joshua Brindle met...@manicmethod.com writes:
Tom Lane wrote:
Right, which is why it's bad for something like a foreign key constraint
to expose the fact that the row does exist after all.
Once again, this is not an issue for us.
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, but you expect that to be a small and predictable cost, say in
the single-digits-percentage range. Plan optimizations that
suddenly stop happening can cost you multiple orders
Tom Lane wrote:
We do not consider that a short coming, anyone who needs to hide
existence of files needs to set up their directory structure to
disallow read/search/create on the directories they aren't allowed to
discover filenames in.
This seems to me to be exactly parallel to deciding
* Joshua Brindle (met...@manicmethod.com) wrote:
They are separate. If you look at the patches you'll see a pgace part,
this is where the core interfaces to the security backends, and you'll
see a rowacl backend and an sepgsql backend.
Right, guess it wasn't clear to me that the PGACE bits
Stephen Frost wrote:
* Joshua Brindle (met...@manicmethod.com) wrote:
They are separate. If you look at the patches you'll see a pgace part,
this is where the core interfaces to the security backends, and you'll
see a rowacl backend and an sepgsql backend.
Right, guess it wasn't clear to me
Ron Mayer rm...@cheapcomplexdevices.com writes:
It seems to me that there are two different standards to which this feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to avoid crafting
The flaw in that argument is that as you are doing it, the
de-optimization only happens on queries that actually need the behavior.
As the SEPostgres patch is constructed, the planner could *never* trust
an FK for optimization since it would have no way to know whether row
level permissions
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote:
Josh Berkus wrote:
Hmmm. Why try to hide individual rows in tables then? That would seem
not in keeping with the filesystem policies.
Because rows have data in them. It is analogous to not
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote:
Josh Berkus wrote:
Hmmm. Why try to hide individual rows in tables then? That would seem
not in keeping with the filesystem policies.
Because rows have data in them. It is
On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
Such app already exists:
http://ozlabs.org/~jk/projects/patchwork/
So it's a matter of just setting it up.
I was in fact in the process of setting that up just now. :-)
--
Sent via pgsql-hackers mailing list
On Tuesday 27 January 2009 16:48:21 Sam Mason wrote:
though at EAL1 they're quite far from the EAL4+ that DB2,
Oracle, etc get.
As far as I understand, the different levels are about assuring a
set of code/features to some assurance level. The Wikipedia page[1]
gives a reasonable overview
On Tuesday 27 January 2009 16:36:50 Stephen Frost wrote:
* 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
Ron Mayer rm...@cheapcomplexdevices.com writes:
Tom Lane wrote:
This seems to me to be exactly parallel to deciding that SELinux should
control only table/column permissions within SQL; an approach that would
be enormously less controversial, less expensive, and more reliable than
what
Tom Lane wrote:
Ron Mayer rm...@cheapcomplexdevices.com writes:
It seems to me that there are two different standards to which this feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to
On Tuesday 27 January 2009 19:10:40 Gregory Stark wrote:
It does seem weird to simply omit records rather than throw an error and
require the user to use a where clause, even if it's something like WHERE
pg_accessible(tab).
Not to pick on you personally, but this is the kind of review that
Peter Eisentraut pete...@gmx.net writes:
Not to pick on you personally, but this is the kind of review that should
have
happened six months ago, not during a why is our development process
inadequate discussion on the eve of beta.
Right now, today, in this thread, is the first time that
* Peter Eisentraut (pete...@gmx.net) wrote:
The SQL spec doesn't define row-level security, and coming
up with something willy-nilly on our own doesn't really strike me as the
best approach.
Exactly. But there is plenty of discussion on that elsewhere.
That's the nice thing about the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Peter Eisentraut pete...@gmx.net writes:
Not to pick on you personally, but this is the kind of review that should
have
happened six months ago, not during a why is our development process
inadequate discussion on the eve of beta.
Right now,
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 27 January 2009 16:36:50 Stephen Frost wrote:
The SQL spec doesn't define row-level security, and coming
up with something willy-nilly on our own doesn't really strike me as the
best approach.
Exactly. But there is plenty of discussion on
Stephen Frost sfr...@snowman.net writes:
Personally, I think it'd be terrible to implement the suggestion that
started this sub-thread since it breaks with what is currently done
elsewhere and what the users of this feature would expect.
Upthread we were being told that this patch breaks new
On 1/27/09, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
Such app already exists:
http://ozlabs.org/~jk/projects/patchwork/
So it's a matter of just setting it up.
I was in fact in the process of setting that up just now. :-)
* Tom Lane (t...@sss.pgh.pa.us) wrote:
BTW, whilst we are being beat about the head and shoulders with how
Oracle et al already have features like this, it is entirely appropriate
to wonder how come it's not in the standard. Those companies surely
pretty much control the standards committee,
Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
Personally, I think it'd be terrible to implement the suggestion that
started this sub-thread since it breaks with what is currently done
elsewhere and what the users of this feature would expect.
Upthread we were being told that this
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Personally, I think it'd be terrible to implement the suggestion that
started this sub-thread since it breaks with what is currently done
elsewhere and what the users of this feature would expect.
Upthread we
On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote:
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres.
FWIW, as you know, sepostgresql is already included in
Devrim GÜNDÜZ wrote:
On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote:
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres.
FWIW, as you know, sepostgresql is
* Devrim GÜNDÜZ (dev...@gunduz.org) wrote:
On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote:
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres.
FWIW, as you
On Tue, 2009-01-27 at 15:46 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Not to pick on you personally, but this is the kind of review that should
have
happened six months ago, not during a why is our development process
inadequate discussion on the eve of beta.
On Mon, Jan 26, 2009 at 08:28:32PM -0500, Tom Lane wrote:
Hmm, you think selinux people read pgsql-announce?
Maybe not, but it got it onto LWN, which is a lot more people.
Have a nice day,
--
Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/
Please line up in a tree and
Joshua Brindle wrote:
FWIW, as you know, sepostgresql is already included in Fedora. You can
continue shipping it as a seperate RPM set.
That is non-ideal. Getting the capability in to the standard database
shipped with RHEL is very important to me and my customers.
Could you speak - even
On Monday 26 January 2009 15:13:56 dp...@pgadmin.org wrote:
On 1/26/09, Josh Berkus j...@agliodbs.com 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
Marko Kreen wrote:
On 1/27/09, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
Such app already exists:
http://ozlabs.org/~jk/projects/patchwork/
So it's a matter of just setting it up.
I was in fact in the process of setting
On Tuesday 27 January 2009 11:56:51 Simon Riggs wrote:
On Tue, 2009-01-27 at 11:36 -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote:
I don't think this is correct.
I do.
People literally grab my shoulder and
That's modest. I've talked to several oracle and db2 shops that want a standby
for reporting that has relatively easy setup/maintenance (handling ddl is a
big part of this) and the HS feature your working on will give them something
as good as what they are getting now. So yeah, HS appeals to
On 1/27/09 4:40 PM, Ron Mayer rm...@cheapcomplexdevices.com wrote:
Joshua Brindle wrote:
FWIW, as you know, sepostgresql is already included in Fedora. You can
continue shipping it as a seperate RPM set.
That is non-ideal. Getting the capability in to the standard database
shipped with
On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote:
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
Robert Treat xzi...@users.sourceforge.net writes:
Now I am starting to think that we cannot prevent large patches from showing
up at the end of a cycle no matter what, and the only way to really solve
that problem is to lesson the pain of getting bumped from a release. Ie.
instead of being
On Tue, 27 Jan 2009, Chad Sellers wrote:
I'll speak to this a bit (Josh is also a Tresys employee). I can't say who
my customers are, but I can speak to their needs. They really need row-level
mandatory access controls (so both).
From the perspective of what this would buy as far as this
Robert Treat xzi...@users.sourceforge.net writes:
On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote:
We have tried the short release cycle before, it was called 8.2. It
fails, remarkably.
I think this is a bit of revisionsit history.
JD got the release number wrong, it was 8.3, but
On Tuesday 27 January 2009 18:51:01 Tom Lane wrote:
Robert Treat xzi...@users.sourceforge.net writes:
Now I am starting to think that we cannot prevent large patches from
showing up at the end of a cycle no matter what, and the only way to
really solve that problem is to lesson the pain of
Here is morning now, so I started to follow the discussion now...
Stephen Frost wrote:
* Gregory Stark (st...@enterprisedb.com) wrote:
It does seem weird to simply omit records rather than throw an error and
require the user to use a where clause, even if it's something like WHERE
On Tuesday 27 January 2009 19:04:49 Tom Lane wrote:
Robert Treat xzi...@users.sourceforge.net writes:
On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote:
We have tried the short release cycle before, it was called 8.2. It
fails, remarkably.
I think this is a bit of revisionsit
Joshua Brindle wrote:
Tom Lane wrote:
Ron Mayer rm...@cheapcomplexdevices.com writes:
It seems to me that there are two different standards to which this
feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long
On 1/27/09 6:57 PM, Greg Smith gsm...@gregsmith.com wrote:
On Tue, 27 Jan 2009, Chad Sellers wrote:
I'll speak to this a bit (Josh is also a Tresys employee). I can't say who
my customers are, but I can speak to their needs. They really need row-level
mandatory access controls (so both).
Robert Treat xzi...@users.sourceforge.net writes:
The more I think about it, the more I feel that where we failed for 8.3 was
not having a short 8.4 cycle lined up, which would give more freedom to bump
patches to the next release.
Heh. The reason we wanted a short 8.3 cycle was so we
On Tue, 2009-01-27 at 21:07 -0500, Tom Lane wrote:
Robert Treat xzi...@users.sourceforge.net writes:
The more I think about it, the more I feel that where we failed for 8.3 was
not having a short 8.4 cycle lined up, which would give more freedom to
bump
patches to the next release.
Andrew Sullivan wrote:
On Tue, Jan 27, 2009 at 12:41:36PM -0500, Stephen Frost wrote:
* Gregory Stark (st...@enterprisedb.com) wrote:
It does seem weird to simply omit records rather than throw an error and
require the user to use a where clause, even if it's something like WHERE
Tom Lane wrote:
Heh. The reason we wanted a short 8.3 cycle was so we could push out
patches that had been held over from 8.2. We are going to have exactly
no credibility if we tell Simon et al we're pushing these patches to
8.5, but don't worry, it'll be a short release cycle.
I think
Tom Lane wrote:
Joshua Brindle met...@manicmethod.com writes:
Tom Lane wrote:
Right, which is why it's bad for something like a foreign key constraint
to expose the fact that the row does exist after all.
Once again, this is not an issue for us.
Yes it is an issue; claiming it isn't
Ron Mayer rm...@cheapcomplexdevices.com writes:
Tom Lane wrote:
I think the best thing we could do overall is to set release dates and
stick to them.
On the other hand, we might be better throwing out release dates
and releasing at the end of any Commit Fest where there is enough
Joshua Brindle wrote:
Stephen Frost wrote:
* Joshua Brindle (met...@manicmethod.com) wrote:
They are separate. If you look at the patches you'll see a pgace
part, this is where the core interfaces to the security backends, and
you'll see a rowacl backend and an sepgsql backend.
Right, guess
I think the best thing we could do overall is to set release dates and
stick to them. If your patch is not ready, well, at least it will get
out in a defined amount of time. Right now, the *real* problem with it
being pushed to the next release is you don't know how successful some
other
On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This seems to me to be exactly parallel to deciding that SELinux should
control only table/column permissions within SQL; an approach that would
be enormously less controversial, less expensive, and more reliable than
what
On Wed, 28 Jan 2009, KaiGai Kohei wrote:
It shows a fact that not negligible number of users accept row-level
granularity, even if it has covert channels.
From my read of the examples that Chad provided, keeping the existence of
things secret from complete outsiders doesn't look like the
Tom Lane wrote:
The flaw in that argument is that as you are doing it, the
de-optimization only happens on queries that actually need the behavior.
As the SEPostgres patch is constructed, the planner could *never* trust
an FK for optimization since it would have no way to know whether row
Jaime Casanova wrote:
On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This seems to me to be exactly parallel to deciding that SELinux should
control only table/column permissions within SQL; an approach that would
be enormously less controversial, less expensive, and more
Greg Smith wrote:
Where I suspect this is all is going to settle down into is that if 1)
the SE GUC is on and 2) one of the tables in a join has rows filtered,
then you can expect that a) it's possible that the result will leak
information, which certainly need to be documented, and b) the
On Tuesday 27 January 2009 21:07:48 Tom Lane wrote:
Robert Treat xzi...@users.sourceforge.net writes:
The more I think about it, the more I feel that where we failed for 8.3
was not having a short 8.4 cycle lined up, which would give more freedom
to bump patches to the next release.
Heh.
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
Marko Kreen wrote:
On 1/27/09, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
Such app already exists:
http://ozlabs.org/~jk/projects/patchwork/
So it's a matter of
Simon Riggs si...@2ndquadrant.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Gregory Stark st...@enterprisedb.com 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
Tom Lane t...@sss.pgh.pa.us writes:
Gregory Stark st...@enterprisedb.com 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
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gregory Stark st...@enterprisedb.com 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 1/26/09, Tom Lane t...@sss.pgh.pa.us wrote:
Gregory Stark st...@enterprisedb.com 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
On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure mmonc...@gmail.com 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
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us 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
Jonah H. Harris jonah.har...@gmail.com writes:
On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure mmonc...@gmail.com 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
On 1/26/09, Jonah H. Harris jonah.har...@gmail.com wrote:
On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure mmonc...@gmail.com 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
On Mon, Jan 26, 2009 at 11:33 AM, Tom Lane t...@sss.pgh.pa.us 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.
[
Tom Lane t...@sss.pgh.pa.us writes:
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us 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
Dave Page wrote:
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This is pretty much exactly how I see it. *Hot standby is not ready*,
So can you give us an idea of
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Jan 26, 2009 at 11:44 AM, Jonah H. Harris
jonah.har...@gmail.com wrote:
On Mon, Jan 26, 2009 at 11:33 AM, Tom Lane t...@sss.pgh.pa.us 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
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?
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
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 that
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 j...@agliodbs.com 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
101 - 200 of 257 matches
Mail list logo
