Re: 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(at)postgresql(dot)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(at)postgresql(dot)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(at)lerctr(dot)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(at)gmx(dot)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(at)gmx(dot)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(at)postgresql(dot)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(at)gmx(dot)net

Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)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(at)postgresql(dot)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(at)Yahoo(dot)com #

Jan Wieck wrote:
> Gaetano Mendola wrote:
>
>> Tom Lane wrote:
>>
>>> "Marc G. Fournier" <scrappy(at)postgresql(dot)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.