Thread: 7.4RC1 tag'd, branched and bundled ...
As Tom announced on Friday, Release Candidate 1 has now been tag'd and bundled ... please test to confirm that nothing seems off with this build ... I'm going to do a broader announce on it tonight, to the -announce and -general lists ... Also, I've created a branch (REL7_4_STABLE) so that work on v7.5 can proceed for those sitting on stuff ... committers, please make sure you check out -rREL7_4_STABLE before applying any patches that need to be in v7.4 final release ... Unless anyone finds anything amiss with RC1, and pending any docs changes between now and then, we could have a full release as early as next Monday *cross fingers* In order to help the advocacy group with the formally press release, and unless something *major* gets detected afterwards, testers have until Thursday of the final week, after which time the final release is "set in stone" ... note that I did say unless something major happens between Thursday and the following Monday ... this gives the advocacy team 3 days to 'tie up loose ends' with the various translations ...
--On Monday, November 03, 2003 01:38:54 -0400 "Marc G. Fournier" <scrappy@postgresql.org> wrote: > > As Tom announced on Friday, Release Candidate 1 has now been tag'd and > bundled ... please test to confirm that nothing seems off with this build > ... > > I'm going to do a broader announce on it tonight, to the -announce and > -general lists ... > > Also, I've created a branch (REL7_4_STABLE) so that work on v7.5 can > proceed for those sitting on stuff ... committers, please make sure you > check out -rREL7_4_STABLE before applying any patches that need to be in > v7.4 final release ... > > Unless anyone finds anything amiss with RC1, and pending any docs changes > between now and then, we could have a full release as early as next Monday > *cross fingers* > > In order to help the advocacy group with the formally press release, and > unless something *major* gets detected afterwards, testers have until > Thursday of the final week, after which time the final release is "set in > stone" ... note that I did say unless something major happens between > Thursday and the following Monday ... this gives the advocacy team 3 days > to 'tie up loose ends' with the various translations ... > I'd like to see my UnixWare compiler detection change applied before final. (I was hoping for Pre-RC1, but obviously that didn't happen). LER > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Marc G. Fournier writes: > As Tom announced on Friday, Release Candidate 1 has now been tag'd and > bundled ... Can you please sometime decide once and for all how you're going to name the tarballs and then communicate that information to the group? Is it rc1 or RC1, beta2 or b2? It's not that there is a technical problem with any of these choices, but the amount of randomness in this process just scares me with every new release you make. > please test to confirm that nothing seems off with this build The tarball contains a file doc/man-7.4.tar.gz, but the makefiles expect to see a file doc/man.tar.gz. -- Peter Eisentraut peter_e@gmx.net
On Mon, 3 Nov 2003, Peter Eisentraut wrote: > Marc G. Fournier writes: > > > As Tom announced on Friday, Release Candidate 1 has now been tag'd and > > bundled ... > > Can you please sometime decide once and for all how you're going to name > the tarballs and then communicate that information to the group? Is it > rc1 or RC1, beta2 or b2? It's not that there is a technical problem with > any of these choices, but the amount of randomness in this process just > scares me with every new release you make. Why does it scare you? *raised eyebrow* As for beta, I used 'beta#' throughout this release cycle, and will use RC# for the release candidate(s) ... > > please test to confirm that nothing seems off with this build > > The tarball contains a file doc/man-7.4.tar.gz, but the makefiles expect > to see a file doc/man.tar.gz. k, am re-generating with the change in place ...
Marc G. Fournier writes: > Why does it scare you? *raised eyebrow* Because release-making should be a predictable process. But if every other release brings a new surprise in the naming scheme, it's not. -- Peter Eisentraut peter_e@gmx.net
Marc G. Fournier wrote: > As Tom announced on Friday, Release Candidate 1 has now been tag'd and > bundled ... please test to confirm that nothing seems off with this build Is in the last Tom's patch about Vacuum sleep between pages ? Regards Gaetano Mendola
On Tue, 4 Nov 2003, Gaetano Mendola wrote: > Marc G. Fournier wrote: > > As Tom announced on Friday, Release Candidate 1 has now been tag'd and > > bundled ... please test to confirm that nothing seems off with this build > > Is in the last Tom's patch about Vacuum sleep between pages ? that won't be in v7.4, to the best of my knowledge ...
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Tue, 4 Nov 2003, Gaetano Mendola wrote:
>> Is in the last Tom's patch about Vacuum sleep between pages ?
> that won't be in v7.4, to the best of my knowledge ...
Definitely not. It's a very experimental patch.
regards, tom lane
Marc G. Fournier writes: > As for beta, I used 'beta#' throughout this release cycle, and will use > RC# for the release candidate(s) ... Actually, this messes up the lexicographical ordering of the release tarballs in directory listings, upgrade schemes, etc., so please don't do this again. -- Peter Eisentraut peter_e@gmx.net
Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > >>On Tue, 4 Nov 2003, Gaetano Mendola wrote: >> >>>Is in the last Tom's patch about Vacuum sleep between pages ? > > >>that won't be in v7.4, to the best of my knowledge ... > > > Definitely not. It's a very experimental patch. I not agree, is an experimental patch that introduce just a delay, you now it better than me, and this delay can be shipped with a default value 0. Alias an experimental feature that can be disabled. I think that we are going to see a lot of 7.4 installation with that patch applied. Gaetano
Gaetano Mendola wrote: > Tom Lane wrote: >> "Marc G. Fournier" <scrappy@postgresql.org> writes: >> >>>On Tue, 4 Nov 2003, Gaetano Mendola wrote: >>> >>>>Is in the last Tom's patch about Vacuum sleep between pages ? >> >> >>>that won't be in v7.4, to the best of my knowledge ... >> >> >> Definitely not. It's a very experimental patch. > > I not agree, is an experimental patch that introduce just > a delay, you now it better than me, and this delay can be > shipped with a default value 0. > Alias an experimental feature that can be disabled. Something that knowingly introduces portability issues and platform dependant behaviour is absolutely inacceptable this late in the release cycle where we already have a significant number of platform reports. Configurable or not doesn't matter. > > I think that we are going to see a lot of 7.4 installation > with that patch applied. We are using usleep() and other equally risky functionality here to quickly get something hooked together that confirms one theory or another. We explicitly discourage people from attempting to squeeze this sort of theory evaluation code into production installations. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > Gaetano Mendola wrote: > >> Tom Lane wrote: >> >>> "Marc G. Fournier" <scrappy@postgresql.org> writes: >>> >>>> On Tue, 4 Nov 2003, Gaetano Mendola wrote: >>>> >>>>> Is in the last Tom's patch about Vacuum sleep between pages ? >>> >>> >>> >>>> that won't be in v7.4, to the best of my knowledge ... >>> >>> >>> >>> Definitely not. It's a very experimental patch. >> >> >> I not agree, is an experimental patch that introduce just >> a delay, you now it better than me, and this delay can be >> shipped with a default value 0. >> Alias an experimental feature that can be disabled. > > > Something that knowingly introduces portability issues and platform > dependant behaviour is absolutely inacceptable this late in the release > cycle where we already have a significant number of platform reports. > Configurable or not doesn't matter. I see your point, anyway we'll see on the road how much people that know the existence of that patch will have in production a 7.4 + the patch. May be an User Survey will be usefull ? I spoke for my reality where with postgres we manage a service that must be up and running 24/24 h 7/7 d. ( http://www.myopensky.com/os/OSwork.html ) I'm really stressed by the peoples that manage the service about to do an Oracle migration, and the argumentation is always about the vacuum procedure that push down the db performances. >> >> I think that we are going to see a lot of 7.4 installation >> with that patch applied. > > > We are using usleep() and other equally risky functionality here to > quickly get something hooked together that confirms one theory or > another. We explicitly discourage people from attempting to squeeze this > sort of theory evaluation code into production installations. I agree in general with you for these "general" arguments, but here we are talking about to introduce a sleep ( removable by guc ) or not! What about the hash refactoring introduced with 7.4? Are you going to discourage people to use the hash? Regards Gaetano Mendola
On Tue, Nov 04, 2003 at 05:35:42PM +0100, Gaetano Mendola wrote: > I agree in general with you for these "general" arguments, but here we > are talking about to introduce a sleep ( removable by guc ) or not! What > about the hash refactoring introduced with 7.4? Are you going to > discourage people to use the hash? Hashed subselect handling was tested by lots of people during a lot of time, and was subject of the working port reports the last few days. This patch has had none of those. Of course, if you want to patch your servers with it no one will stop you, but it will be _your_ responsability. You can do any amount of testing you want to make sure it's good enough for you. And you are welcome to report how it did behave. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Investigación es lo que hago cuando no sé lo que estoy haciendo" (Wernher von Braun)
Alvaro Herrera wrote: > On Tue, Nov 04, 2003 at 05:35:42PM +0100, Gaetano Mendola wrote: > > >>I agree in general with you for these "general" arguments, but here we >>are talking about to introduce a sleep ( removable by guc ) or not! What >>about the hash refactoring introduced with 7.4? Are you going to >>discourage people to use the hash? > > > Hashed subselect handling was tested by lots of people during a lot of > time, and was subject of the working port reports the last few days. > This patch has had none of those. > > Of course, if you want to patch your servers with it no one will stop > you, but it will be _your_ responsability. You can do any amount of > testing you want to make sure it's good enough for you. And you are > welcome to report how it did behave. I will with pleasure. Regards Gaetano Mendola
On Tue, 4 Nov 2003, Gaetano Mendola wrote: > I agree in general with you for these "general" arguments, but here we > are talking about to introduce a sleep ( removable by guc ) or not! What > about the hash refactoring introduced with 7.4? Are you going to > discourage people to use the hash? That's not fair. Everyone's had the chance to test 7.4 betas 1 through 4 on their own hardware to see if it is safe and stable. If I've load tested the betas and found them reliable, and suddenly find that 7.4 rc1 or release were to be less reliable (I'm not talking about THIS patch in particular, I'm talking about ANY patch...) than the betas I would be upset that the change happened at the end instead of the beginning of the release cycle. I think this patch is a great idea, but it's probably got a lot of refinement coming down the line. I'd be glad to test it on the 7.4 branch as a patch, but it's just too late to put performance enhancements into the main branch. Now is bug fixing time, not performance tweaking time. That was pre-beta1 really. To review: The hasgagg has had testing, and lots of it, by the people who need it. This patch has had little testing. While I'm sure it's a fairly safe change, and likely to be a good thing overall, it's just too late in the cycle for it to get in.