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
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 downt
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
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
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 8.0
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
>
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
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-rel
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
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
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 L
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
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. W
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
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
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 h
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 tha
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, 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
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 someo
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,
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
...
>
> 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 exe
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 star
> > 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'
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 ...
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
"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
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 :(
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 -ge
--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 pr
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 large,
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 an
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 sugg
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 p
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
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 rel
"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 le
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
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 s
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
a
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
"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 pr
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, w
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
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
s
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 th
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
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 wo
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
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
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 wrot
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-mon
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:
> 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 peop
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
56 matches
Mail list logo
