From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Win32, PITR, nested transactions, tablespaces |
Date: | 2004-05-29 14:04:04 |
Message-ID: | 87vfif9vor.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > This is the only place where I see hardly any movement on major items the
> > whole development cycle, then a rush of radical changes just before the
> > freeze.
>
> [blink] There's been plenty of stuff done all through this development
> cycle (and previous ones too). Read the CVS logs if you've forgotten.
Sure, but that's parallel to what I'm saying. This is the only place I see
"Please delay the freeze so I can squeeze this major change in just before the
release". In other projects I see "Please hurry up and release so I can start
committing major changes again".
Perhaps it's an artifact of people doing most of their work offline and
submitting patches, rather than using the CVS tree as their development
environment. Or perhaps it's an artifact of ~nobody using the CVS version of
postgres except for testing patches. Or perhaps it's a consequence of the
freeze period being so long.
Or perhaps the serious postgres developers are just so good that they're
justified in being confident applying major changes just before a freeze.
Experience does seem to justify that somewhat; I've been repeatedly impressed
at how such drastic changes seem to just work with hardly any changes.
Fwiw, I do feel that 7.4 is pretty fresh. At least in my case I don't plan on
upgrading to 7.5 immediately because 7.4 meets all our needs. When we upgrade
it'll probably be for PITR, but we don't really need it yet.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-05-29 14:13:07 | Re: Extended customizing, SQL functions, |
Previous Message | Shridhar Daithankar | 2004-05-29 13:52:49 | Re: Extended customizing, SQL functions, |