Joshua D. Drake wrote:
On Mon, 2009-01-12 at 13:23 -0500, Robert Haas wrote:
But wasn't I just reading something about having to wipe that repository
and re-import the CVS history to fix various problems?
Not sure; I hope not.
Actually yes we did. There was a bug in git-cvs that we fixed.
Aidan Van Dyk wrote:
With git, you pull down the complete *history* of whatever branch, tag,
or reference you want to pull down.
You can do a so-called shallow clone, pulling only X most recent
commits, with git clone --depth=X. There's some limitations on what
you can do with a shallow
On Mon, 2009-01-12 at 20:52 -0500, Robert Haas wrote:
I think the
base backup should be integrated into the mechanism as well. I want
to just be able to configure the master and slave for replication,
fire up the slave, and walk away. Without that, I agree that it's
likely to be too
Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
Tom Lane wrote:
David Fetter da...@fetter.org writes:
1. Remove the messages size limits on -hackers. They serve no useful
purpose, and they interfere with our development process.
Agreed, or at least boost it up a good
Joshua D. Drake wrote:
Does bzr, mecurial or monotone offer the same or better solution? Bzr in
particular is in very wide use and I run into mecurial all the time.
I have found that mercurial is pretty much feature-equivalent to git, at
least until you get to the really wizard-like use
Robert Haas wrote:
I am just explaining how it works in practice. If the patch is still
being improved, the feeling is that the author wants more time to adjust
things, and with other things on our plate, we are glad to leave their
patch until last.
Well, it's good that you have an
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Robert Haas wrote:
(It would be interesting to here how much value people think it has
added, and get suggestions on how to do things better next time.)
I'm not sure how much round-robin-review has taken load off committers,
you
Tom Lane t...@sss.pgh.pa.us writes:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Robert Haas wrote:
(It would be interesting to here how much value people think it has
added, and get suggestions on how to do things better next time.)
I'm not sure how much
On Sun, 2009-01-11 at 12:07 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Recovery doesn't have a test framework as yet. I would like to add one
for this release, especially since we have so much recovery-related code
being added to the release (and manual testing is so
Simon Riggs si...@2ndquadrant.com writes:
Is it flaky? Not fundamentally; code wise I see it more as a
question of time.
a question of time indeed.
If we insist upon cuts, ...
Even if we reject replication entirely ...
There's a clear difference between how you're thinking about this and
Gregory Stark st...@enterprisedb.com writes:
... But from my point of view it would
just always be better to commit large patches immediately after forking a
release instead of just before the beta to give them a whole release cycle of
exposure to developers before beta testers.
I'm in favor
On Mon, 2009-01-12 at 09:04 -0500, Tom Lane wrote:
I wasn't trying to start
a discussion about general project policies, but about the specific
status of this particular group of patches.
Which ones exactly?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-01-12 at 09:04 -0500, Tom Lane wrote:
I wasn't trying to start
a discussion about general project policies, but about the specific
status of this particular group of patches.
Which ones exactly?
Well, one of the things that makes me
On Mon, 2009-01-12 at 09:55 -0500, Tom Lane wrote:
(And for the record,
there is nothing I like even a little bit about the practice of posting
a URL instead of an actual patch.)
I don't like it either.
The patchsets are too big to post to the list directly, at least that is
the reason in my
Simon Riggs wrote:
On Mon, 2009-01-12 at 09:55 -0500, Tom Lane wrote:
(And for the record,
there is nothing I like even a little bit about the practice of posting
a URL instead of an actual patch.)
I don't like it either.
The patchsets are too big to post to the list directly, at least that
On Mon, Jan 12, 2009 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, we are getting off onto a tangent. I wasn't trying to start
a discussion about general project policies, but about the specific
status of this particular group of patches.
I concur with Gregory on this one.
Simon Riggs wrote:
Recovery doesn't have a test framework as yet.
I have been having these concerns as well. In fact, I recall
discussions at least 8 years back about how pg_dump doesn't really have
any organized testing, and we also have little regular testing of PITR
aside from specific
On 1/12/09, Guillaume Smet guillaume.s...@gmail.com wrote:
On Mon, Jan 12, 2009 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, we are getting off onto a tangent. I wasn't trying to start
a discussion about general project policies, but about the specific
status of this
On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure mmonc...@gmail.com wrote:
I disagree at least with hot standby. I've been using/testing (as
have others) it under a variety of workloads for several months now
with no issues outside of corrected issues in the very early patches.
Also, a
On Mon, Jan 12, 2009 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-01-12 at 09:04 -0500, Tom Lane wrote:
Well, one of the things that makes me uncomfortable is that it's not
even clear exactly which set of patches is currently proposed
Guillaume Smet guillaume.s...@gmail.com writes:
On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure mmonc...@gmail.com wrote:
I disagree at least with hot standby. I've been using/testing (as
have others) it under a variety of workloads for several months now
with no issues outside of corrected
On Mon, Jan 12, 2009 at 11:07 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure mmonc...@gmail.com wrote:
I disagree at least with hot standby. I've been using/testing (as
have others) it under a variety of workloads for several months now
with
On Mon, Jan 12, 2009 at 11:11:20AM -0500, Greg Stark wrote:
On Mon, Jan 12, 2009 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-01-12 at 09:04 -0500, Tom Lane wrote:
Well, one of the things that makes me uncomfortable is that it's
David Fetter da...@fetter.org writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no useful
purpose, and they interfere with our development process.
Agreed, or at least boost it up a good bit more.
If -hackers
isn't
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
My point is that what Simon currently has (and so what you tested) is
different from what is going to be commited (note the final in what
I wrote) and I suspect there will be a certain number of non
negligible adjustments (see the last
On Mon, 2009-01-12 at 11:33 -0500, Tom Lane wrote:
If -hackers
isn't already subscriber-only, now would be the time to make it so.
Not sure how that's relevant?
So we don't get spam patches.
Joshua D. Drake
regards, tom lane
--
PostgreSQL
Consulting,
On Mon, Jan 12, 2009 at 11:33:43AM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no
useful purpose, and they interfere with our development process.
Agreed,
On Mon, Jan 12, 2009 at 5:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Basically I think we are up against the same type of project management
decision we've had several times before: are we willing to slip the
8.4 release schedule for however long it will take for hot standby
and the other
On 1/12/09, Joshua D. Drake j...@commandprompt.com wrote:
Basically I think we are up against the same type of project management
decision we've had several times before: are we willing to slip the
8.4 release schedule for however long it will take for hot standby
and the other
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake j...@commandprompt.com wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
Basically I think we are up against the same type of project management
decision we've had several times before: are we willing to slip the
8.4 release schedule
On 12 jan 2009, at 17.42, David Fetter da...@fetter.org wrote:
On Mon, Jan 12, 2009 at 11:33:43AM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no
useful
On Mon, Jan 12, 2009 at 05:50:19PM +0100, Magnus Hagander wrote:
2. Start using more git, as many hackers and committers have
already started to do. This is the kind of situation where CVS
just plain falls down because branching and merging are
unmanageably difficult in it, where in git,
On 2009-01-12, at 16:48, Dave Page wrote:
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake
j...@commandprompt.com wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
Basically I think we are up against the same type of project
management
decision we've had several times before: are
On Mon, Jan 12, 2009 at 5:48 PM, Dave Page dp...@pgadmin.org wrote:
I would. PostgreSQL is not a commercial application which has to be
released on schedule to satisfy shareholders - it's an Open Source
project that aims to provide it's users with useful features.
It has nothing to do with
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake j...@commandprompt.com
wrote:
I would certainly not like to see 8.4 slip.
I would. PostgreSQL is not a commercial application which has to be
released on schedule to satisfy shareholders - it's an Open
Peter Eisentraut wrote:
Simon Riggs wrote:
Recovery doesn't have a test framework as yet.
I have been having these concerns as well. In fact, I recall
discussions at least 8 years back about how pg_dump doesn't really have
any organized testing, and we also have little regular testing
On Mon, 2009-01-12 at 16:48 +, Dave Page wrote:
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
Basically I think we are up against the same type of project management
decision we've had several times
On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
Yeah, but there are already a number of things in 8.4 that are killer
features for various applications --- window functions and WITH to take
two recently-committed examples. Should we sit
On Mon, 2009-01-12 at 17:27 +, Dave Page wrote:
In general, we have always regretted it in the past when we chose to
slip a release waiting for a specific feature...
I don't recall such a time - though perhaps the last time it happened
was before I was so heavily involved in the
On Mon, Jan 12, 2009 at 5:20 PM, Joshua D. Drake j...@commandprompt.com wrote:
The community are our shareholders.
Exactly - and their dividends are the features we release, not a share
of profits we make from pushing out something a few weeks earlier.
Right. Except that isn't really the
2. Start using more git, as many hackers and committers have already
started to do. This is the kind of situation where CVS just plain
falls down because branching and merging are unmanageably difficult in
it, where in git, they're many-times-a-day operations.
This is a red herring, unless
Tom Lane t...@sss.pgh.pa.us writes:
Yeah, but there are already a number of things in 8.4 that are killer
features for various applications --- window functions and WITH to take
two recently-committed examples. Should we sit on those for however
long it will take to make replication
On Mon, Jan 12, 2009 at 12:27 PM, Dave Page dp...@pgadmin.org wrote:
On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In general, we have always regretted it in the past when we chose to
slip a release waiting for a specific feature...
I don't recall such a time - though
On Mon, 2009-01-12 at 08:37 -0800, Joshua D. Drake wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
My point is that what Simon currently has (and so what you tested) is
different from what is going to be commited (note the final in what
I wrote) and I suspect there will be a
Robert Haas wrote:
2. Start using more git...
This is a red herring, unless your proposal also includes making the
master CVS^H^H^Hgit repository world-writable. The complaint I have
about people posting URLs is that there's no stable archive of what the
patches really were, and just
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 12, 2009 at 5:20 PM, Joshua D. Drake j...@commandprompt.com
wrote:
Well its really nobody's fault except the hacker that didn't step up to
do the work. I believe all hackers have already been working diligently.
They have - but I see no reason
On Mon, Jan 12, 2009 at 5:30 PM, Joshua D. Drake j...@commandprompt.com wrote:
On Mon, 2009-01-12 at 17:27 +, Dave Page wrote:
In general, we have always regretted it in the past when we chose to
slip a release waiting for a specific feature...
I don't recall such a time - though
Robert Haas robertmh...@gmail.com writes:
This is a red herring, unless your proposal also includes making the
master CVS^H^H^Hgit repository world-writable. The complaint I have
about people posting URLs is that there's no stable archive of what the
patches really were, and just because it
Christopher Browne cbbro...@gmail.com writes:
On Mon, Jan 12, 2009 at 12:27 PM, Dave Page dp...@pgadmin.org wrote:
On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In general, we have always regretted it in the past when we chose to
slip a release waiting for a specific
No, git really does help with this. If Simon were making his changes
in git and pushing them to a git branch on git.postgresql.org, you
would be able to see exactly what he changed and when he changed it.
Well, if that's actually an archival repository then it would work.
But wasn't I just
That's happened more than once, though my memory of details is fuzzy
and I don't have time to troll the archives for them right now.
Maybe Bruce can remember without a lot of searching. But our current
policy of time-based releases (ie deadlines) is born of hard experience
with the negative
On Mon, 2009-01-12 at 13:23 -0500, Robert Haas wrote:
No, git really does help with this. If Simon were making his changes
in git and pushing them to a git branch on git.postgresql.org, you
would be able to see exactly what he changed and when he changed it.
Well, if that's actually an
On Mon, 2009-01-12 at 13:04 -0500, Tom Lane wrote:
Simon didn't ramp up
his effort until around September IIRC.
The main topic of snapshot creation was being discussed at PGcon in May
and another sponsors got serious then. I started working on a coherent
detailed design in July, but didn't
Robert Haas wrote:
That's happened more than once, though my memory of details is fuzzy
and I don't have time to troll the archives for them right now.
Maybe Bruce can remember without a lot of searching. But our current
policy of time-based releases (ie deadlines) is born of hard experience
Robert Haas wrote:
git IS a stable archive of what the patches really were.
No. A developer can delete, move and rebase branches in his own
repository as he likes, and all of those operations modify history. In
fact, a developer can completely destroy or take offline his published
On Mon, 2009-01-12 at 20:43 +0200, Heikki Linnakangas wrote:
Robert Haas wrote:
git IS a stable archive of what the patches really were.
No. A developer can delete, move and rebase branches in his own
repository as he likes, and all of those operations modify history. In
fact, a
On Mon, Jan 12, 2009 at 6:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 12, 2009 at 5:20 PM, Joshua D. Drake j...@commandprompt.com
wrote:
Well its really nobody's fault except the hacker that didn't step up to
do the work. I believe all hackers
* Joshua D. Drake j...@commandprompt.com [090112 14:22]:
No. A developer can delete, move and rebase branches in his own
repository as he likes, and all of those operations modify history. In
fact, a developer can completely destroy or take offline his published
repository. It's *not*
Actually yes we did. There was a bug in git-cvs that we fixed. Its is
talked about here:
http://archives.postgresql.org/pgsql-www/2008-12/msg00182.php
But... that wasn't really the fault of git.
OK, but that's in the past now - good. I thought Tom was saying that
it might need to be done
On Mon, 2009-01-12 at 14:31 -0500, Robert Haas wrote:
Actually yes we did. There was a bug in git-cvs that we fixed. Its is
talked about here:
Actually the work is relatively minimal as we have git infrastructure in
place. The larger problem is:
What is the problem we are trying to
On Mon, Jan 12, 2009 at 1:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
git IS a stable archive of what the patches really were.
No. A developer can delete, move and rebase branches in his own repository
as he likes, and all of those operations modify
On Mon, 2009-01-12 at 14:33 -0500, Aidan Van Dyk wrote:
* Joshua D. Drake j...@commandprompt.com [090112 14:22]:
No. A developer can delete, move and rebase branches in his own
repository as he likes, and all of those operations modify history. In
fact, a developer can completely
On Mon, Jan 12, 2009 at 02:36:08PM -0500, Robert Haas wrote:
On Mon, Jan 12, 2009 at 1:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
git IS a stable archive of what the patches really were.
No. A developer can delete, move and rebase branches in
I think the problems it would solve for us are (1) emailing huge
patches around sucks (it sucks unnecessarily because of the
mailing-list size limit, but even if someone fixes that, it still
sucks), (2) no need for a CVS-to-GIT conversion that may incur dirty
reads; (3) retention of history
On Mon, Jan 12, 2009 at 12:20 PM, Joshua D. Drake j...@commandprompt.com
wrote:
IMO, the reasons to delay a release:
Our grammar looks like MySQL
mmm... you mean if we add things like VALUES statement, lastval() and
things like that? ;)
--
Atentamente,
Jaime Casanova
Soporte y
Tom Lane wrote:
David Fetter da...@fetter.org writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no useful
purpose, and they interfere with our development process.
Agreed, or at least boost it up a good bit more.
the
On Mon, 2009-01-12 at 21:35 +0100, Stefan Kaltenbrunner wrote:
Tom Lane wrote:
David Fetter da...@fetter.org writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no useful
purpose, and they interfere with our
However I can say I would be fairly annoyed if everytime I checked
hackers I was pulling down 5 megs in various patches.
Oh... really? I thought we were past the day when anyone cared how
large the attachments were.
At any rate, if we increased the limit from 100k to 1M, you could
conceivably
Dave Page dp...@pgadmin.org wrote:
project that aims to provide it's users with useful features. We
have two extremely useful features here (hot standby and sync
replication) which together will make this a killer release for many
people
Without taking any particular position on this one
On Mon, 2009-01-12 at 16:02 -0500, Robert Haas wrote:
However I can say I would be fairly annoyed if everytime I checked
hackers I was pulling down 5 megs in various patches.
Oh... really? I thought we were past the day when anyone cared how
large the attachments were.
IMO the fact that
On Mon, 2009-01-12 at 15:07 -0600, Kevin Grittner wrote:
Dave Page dp...@pgadmin.org wrote:
project that aims to provide it's users with useful features. We
have two extremely useful features here (hot standby and sync
replication) which together will make this a killer release for many
Joshua D. Drake j...@commandprompt.com wrote:
Who has integrated multi-master (transaction and power outage safe)
replication now?
As far as I recall, nobody there was that specific about the form of
it. PostgreSQL arguably has non-integrated multi-master replication
now, and I've seen
No. A developer can delete, move and rebase branches in his own
repository as he likes, and all of those operations modify
history. In fact, a developer can completely destroy or take
offline his published repository. It's *not* an archive.
We could do this using git's configuration:
Tom Lane wrote:
Christopher Browne cbbro...@gmail.com writes:
On Mon, Jan 12, 2009 at 12:27 PM, Dave Page dp...@pgadmin.org wrote:
On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In general, we have always regretted it in the past when we chose to
slip a release
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
Tom Lane wrote:
David Fetter da...@fetter.org writes:
1. Remove the messages size limits on -hackers. They serve no useful
purpose, and they interfere with our development process.
Agreed, or at least boost it up a good bit more.
the
On Mon, Jan 12, 2009 at 08:12:46PM -0500, Tom Lane wrote:
250K ought to be enough.
...for anybody ;)
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to
Bruce Momjian br...@momjian.us writes:
As for the process used, I think it is useful to understand how
committers choose what to work on next. One criteria is that the patch
has stabilized; if a patch is still be modified regularly, the
committer might as well work on another patch that has
I feel no need to encourage people to send huge patches uncompressed ;-)
gzip normally gets at least 3x or 4x on large diffs. So a limit around
250K ought to be enough.
To paraphrase a leading authority on PostgreSQL development, and with
tongue firmly in cheek, there's something to what you
Gregory Stark wrote:
Now, maybe this is unfair to patches that are frequently updated, but
this is the typical process we follow, and it explains why the patches
above have not gotten near commit status yet.
It's not just unfair. It's counter-productive. It means you're ignoring the
very
Gregory Stark st...@enterprisedb.com writes:
Bruce Momjian br...@momjian.us writes:
As for the process used, I think it is useful to understand how
committers choose what to work on next. ...
It's not just unfair. It's counter-productive. It means you're ignoring the
very patches whose
On Mon, Jan 12, 2009 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Well, I've been keeping an eye on both Hot Standby and Synchronous
Replication patches. IMHO the Hot Standby patch is architecturally sound,
and while I suggested some pretty big changes just recently
I am just explaining how it works in practice. If the patch is still
being improved, the feeling is that the author wants more time to adjust
things, and with other things on our plate, we are glad to leave their
patch until last.
Well, it's good that you have an explanation, but I'm not
Hi,
On Tue, Jan 13, 2009 at 3:32 AM, Robert Haas robertmh...@gmail.com wrote:
One thing I find interesting is that the Infrastructure Changes for
Recovery patch became the foundation for both Hot Standby and
Synchronous Replication. That implies that those changes might be
of somewhat more
Hi,
On Tue, Jan 13, 2009 at 10:52 AM, Robert Haas robertmh...@gmail.com wrote:
IMHO, the synchronous replication isn't in such good shape, I'm afraid. I've
said this before, but I'm not happy with the built from spare parts nature
of it. You shouldn't have to configure an archive, file-based
Simon Riggs si...@2ndquadrant.com writes:
Recovery doesn't have a test framework as yet. I would like to add one
for this release, especially since we have so much recovery-related code
being added to the release (and manual testing is so time consuming).
I've been thinking for some time that
On Sun, Jan 11, 2009 at 12:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Recovery doesn't have a test framework as yet. I would like to add one
for this release, especially since we have so much recovery-related code
being added to the release (and manual
86 matches
Mail list logo
