Any chance you might be able to put together a HOWTO on this? I think it
would be extremely valuable to a lot of people.
On Tue, Nov 25, 2003 at 11:25:34PM -0500, Andrew Sullivan wrote:
On Mon, Nov 24, 2003 at 11:08:44PM -0600, Jim C. Nasby wrote:
Has anyone looked at using replication as a
On Mon, Nov 24, 2003 at 11:08:44PM -0600, Jim C. Nasby wrote:
Has anyone looked at using replication as a migration method? If
Looked at? Sure. Heck, I've done it. Yes, it works. Is it
painless? Well, that depends on whether you think using erserver is
painless. ;-) It's rather less
On Fri, Nov 21, 2003 at 01:32:38PM -0500, Jan Wieck wrote:
bootstrap mode to apply the changes, could be an idea to think of. It
would still require some downtime, but nobody can avoid that when
replacing the postgres binaries anyway, so that's not a real issue. As
long as it eliminates
Quoth [EMAIL PROTECTED] (Jim C. Nasby):
On Fri, Nov 21, 2003 at 01:32:38PM -0500, Jan Wieck wrote:
bootstrap mode to apply the changes, could be an idea to think of. It
would still require some downtime, but nobody can avoid that when
replacing the postgres binaries anyway, so that's not a
On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote:
Yeah, I think the main issue in all this is that for real production
sites, upgrading Postgres across major releases is *painful*. We have
to find a solution to that before it makes sense to speed up the
major-release
Alvaro Herrera wrote:
On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote:
Yeah, I think the main issue in all this is that for real production
sites, upgrading Postgres across major releases is *painful*. We have
to find a solution to that before it makes sense to speed up
Jan Wieck [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
One of the most complex would be to avoid the need of pg_dump for
upgrades ...
We don't need a simple way, we need a way to create some sort of catalog
diff and a safe way to apply that to an existing installation during
the
Hello hackers
Sorry when I am talking to the gurus...
There is a database, which has a concept called Transportable
Tablespace (TTS). Would it not be a verry easy and fast solution to
just do this with the Tables, Index and all non catalog related files.
- You create a new db cluster (e.g
Jan Wieck [EMAIL PROTECTED] writes:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that.
I don't see much of a point for a shorter release cycle as long as we
don't get rid of the initdb
Kevin Brown [EMAIL PROTECTED] writes:
... That's why the release methodology used by the Linux kernel development
team is a reasonable one.
I do not think we have the manpower to manage multiple active
development branches. The Postgres developer community is a fraction of
the size of the
Larry Rosenman [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
1. Start platform testing on day 1 of beta. Last minute fixes for AIX or
UnixWare are really becoming old jokes.
The only reason we had last minute stuff for UnixWare this time was the
timing of PG's release and the UP3
Yeah, I think the main issue in all this is that for real production
sites, upgrading Postgres across major releases is *painful*. We have
to find a solution to that before it makes sense to speed up the
major-release cycle.
Well, I think one of the simplest is to do a topological sort of objects
Marc G. Fournier wrote:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks.
On Tue, 2003-11-18 at 04:36, Marc G. Fournier wrote:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think this is the hard part ...
other
0. As you say, make it known to the public. Have people test
their in-development applications using a beta.
and how do you propose we do that? I think this is the hard part
... other then the first beta, I post a note out to -announce and
-general that the beta's have been tag'd and
On Mon, Nov 17, 2003 at 20:08:41 -0500,
Neil Conway [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.
Why is that?
End users will find it useful.
I started using
...
Does anyone have a comparison of how many lines of code were added in
this release compared to previous?
7.2.4: 456204 lines of code in 1021 files
7.3.4: 480491 lines of code in 1012 files
7.4: 554567 lines of code in 1128 files (boah!)
I used a fresh extracted source-directory and
On Tue, Nov 18, 2003 at 02:33:41PM +0100, Tommi Maekitalo wrote:
...
Does anyone have a comparison of how many lines of code were added in
this release compared to previous?
7.2.4: 456204 lines of code in 1021 files
7.3.4: 480491 lines of code in 1012 files
7.4: 554567 lines of code in
Marc G. Fournier wrote:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think this is the hard part ...
other then the first beta, I post a
Guys,
I agree with Neil ... it's not the length of the development part of the
cycle, it's the length of the beta testing.
I do think an online bug tracker (bugzilla or whatever) would help. I also
think that having a person in charge of testing would help as well ... no
biggie, just
On Tue, Nov 18, 2003 at 09:42:31AM -0800, Josh Berkus wrote:
(Oddly enough, my problem in doing more testing myself is external to
PostgreSQL; most of our apps are PHP apps and you can't compile PHP against
two different versions of PostgreSQL on the same server. Maybe with User
Mode
Josh Berkus wrote:
Guys,
I agree with Neil ... it's not the length of the development part of the
cycle, it's the length of the beta testing.
I do think an online bug tracker (bugzilla or whatever) would help. I also
think that having a person in charge of testing would help as well ... no
On Tue, 18 Nov 2003, Andrew Dunstan wrote:
Josh Berkus wrote:
Guys,
I agree with Neil ... it's not the length of the development part of the
cycle, it's the length of the beta testing.
I do think an online bug tracker (bugzilla or whatever) would help. I also
think that having a
On Tue, Nov 18, 2003 at 12:36:11AM -0400, Marc G. Fournier wrote:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think this is the hard
HOWEVER, a release cycle of *less than 6 months* would kill the advocacy vols
if we wanted the same level of publicity.
I do support the idea of dev releases. For example, if there was a dev
release of PG+ARC as soon as Jan is done with it, I have one client would
would be willing to test it
On Wed, 19 Nov 2003, Christopher Kings-Lynne wrote:
HOWEVER, a release cycle of *less than 6 months* would kill the advocacy vols
if we wanted the same level of publicity.
I do support the idea of dev releases. For example, if there was a dev
release of PG+ARC as soon as Jan is done
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people
Marc G. Fournier writes:
That is the usual goal *nod* Same goal we try for each release, and never
quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
always do :)
I don't see how we could have tried for a 4-month development period and
ended up with an 8-month period.
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
That is the usual goal *nod* Same goal we try for each release, and never
quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
always do :)
I don't see how we could have tried for a 4-month
Just did a quick search on archives, and the original plan was for a
release in mid-2003, which means the beta would have been *at least* a
month before that, so beta starting around May:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php
On Mon, 17 Nov 2003, Marc G. Fournier
Peter Eisentraut [EMAIL PROTECTED] writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.
Why is that?
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
Marc G. Fournier writes:
Just did a quick search on archives, and the original plan was for a
release in mid-2003, which means the beta would have been *at least* a
month before that, so beta starting around May:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php
That was a
Neil Conway writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.
Why is that?
First, if you develop something today, the first time users would
realistically get a hand at it would be
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a
Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always 'just sitting on something that is almost
done' at the end
Hello,
Personally I am for long release cycles, at least for major releases.
In fact
as of 7.4 I think there should possibly be a slow down in releases with more
incremental releases (minor releases) throughout the year.
People are running their companies and lives off of PostgreSQL, they
On Tue, 18 Nov 2003, Christopher Kings-Lynne wrote:
Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
April 1st, or 4 mos from last release, tends to be what we aim for with
all releases ... as everyone knows,
Joshua D. Drake [EMAIL PROTECTED] writes:
Hello,
Personally I am for long release cycles, at least for major releases.
In fact
as of 7.4 I think there should possibly be a slow down in releases with more
incremental releases (minor releases) throughout the year.
That would pretty much
Peter Eisentraut [EMAIL PROTECTED] writes:
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want
that? Don't you want people to use your code?
Sure :-) But I don't mind a long release cycle if it is better for
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
OK, here start the problems. Development already started, so April 1st is
Peter Eisentraut wrote:
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
OK, here start the problems. Development already
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
OK, here start the
Matthew T. O'Connor [EMAIL PROTECTED] writes:
So 7.4 took about 4.5 months to get from feature freeze to release.
I think feature freeze is the important date that developers of new
features need to concern themselves with.
Rather than the length of the release cycle, I think it's the length
Neil Conway wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want
that? Don't you want people to use your code?
Sure :-) But I don't mind a long release cycle
Matthew T. O'Connor wrote:
I agree with Peter's other comment, that the longer the development
cycle, the longer the beta / bug shakeout period, perhaps a shorter dev
cycle would yield a shorter beta period, but perhaps it would also
result in a less solid release.
Perhaps. Perhaps not.
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta process on www.postgresql.org
for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
what we can do to
Neil Conway writes:
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta process on www.postgresql.org
for 7.4 was pretty ridiculous. Does anyone else have a
On Mon, 17 Nov 2003, Neil Conway wrote:
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta process on www.postgresql.org
for 7.4 was pretty ridiculous. Does
eg. Someone who just knows how to use postgres could test my upcoming
COMMENT ON patch. (It's best if I myself do not test it) Someone with
more skill with a debugger can be asked to test unique hash indexes by
playing with concurrency, etc.
I forgot to mention that people who just have
--On Tuesday, November 18, 2003 04:43:12 +0100 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Neil Conway writes:
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think this is the hard part ...
other then the first beta, I post a note out to -announce and
On Mon, 17 Nov 2003, Larry Rosenman wrote:
I try to test stuff fairly frequently, and this time I didn't know when,
exactly, SCO would make the release of the updated compiler.
And there was no way you could predict that your contact there would take
off on holidays either :(
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think this is the hard part
(1) Make the beta more
On Tue, 18 Nov 2003, Neil Conway wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think
56 matches
Mail list logo
