Thread: Ready for beta2?

Ready for beta2?

From
Bruce Momjian
Date:
We have had very few beta1 issues.  I am thinking we should release
beta2 next week and perhaps accelerate beta and consider a final release
in November rather than December.  Because of the length of our feature
freeze it is possible we are not going to have as many beta bugs.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: Ready for beta2?

From
Albert Cervera i Areny
Date:
A Diumenge 21 Octubre 2007, Bruce Momjian va escriure:
> We have had very few beta1 issues.  I am thinking we should release
> beta2 next week and perhaps accelerate beta and consider a final release
> in November rather than December.  Because of the length of our feature
> freeze it is possible we are not going to have as many beta bugs.

I want to send a patch for the contrib modules by late sunday (europe here ;). 
I'm doing some cleanup and organizing it a bit better and I think somebody 
expected these docs to be in the second beta...

-- 
Albert Cervera i Areny
http://www.NaN-tic.com


Re: Ready for beta2?

From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> writes:
> We have had very few beta1 issues.  I am thinking we should release
> beta2 next week and perhaps accelerate beta and consider a final release
> in November rather than December.  Because of the length of our feature
> freeze it is possible we are not going to have as many beta bugs.

We need to deal with the open questions about tsearch API before beta2.
Since we've already forced initdb for beta2, there's no cost to
additional system-catalog changes now, but that window will clang shut
again when beta2 goes out.

I'm disappointed that Oleg and Teodor haven't commented on those issues
yet ...
        regards, tom lane


Re: Ready for beta2?

From
Josh Berkus
Date:
Bruce Momjian wrote:
> We have had very few beta1 issues.  I am thinking we should release
> beta2 next week and perhaps accelerate beta and consider a final release
> in November rather than December.  Because of the length of our feature
> freeze it is possible we are not going to have as many beta bugs.
> 

Unfortunately, I think that's because people haven't been testing.  At 
my keynote at the PostgreSQL Fall Conference yesterday, I asked the 
audience of 63 people how many had built 8.3 beta and tried to run 
something on it ... 3.  And these are our enthusiasts.

For me, I ran into a CC compile issues on Solaris (diagnosing now) and 
haven't got much further on testing it there, although Jignesh is 
already into performance testing.  Worked fine for demo purposes on 
OSX.4, though, and I was able to import some old databases (Staffos, 
TPCE) without unexpected issues.

Of course I would like to do a short beta, but I think we need to harass 
people to test more.

--Josh


Re: Ready for beta2?

From
Bruce Momjian
Date:
Josh Berkus wrote:
> Bruce Momjian wrote:
> > We have had very few beta1 issues.  I am thinking we should release
> > beta2 next week and perhaps accelerate beta and consider a final release
> > in November rather than December.  Because of the length of our feature
> > freeze it is possible we are not going to have as many beta bugs.
> > 
> 
> Unfortunately, I think that's because people haven't been testing.  At 
> my keynote at the PostgreSQL Fall Conference yesterday, I asked the 
> audience of 63 people how many had built 8.3 beta and tried to run 
> something on it ... 3.  And these are our enthusiasts.
> 
> For me, I ran into a CC compile issues on Solaris (diagnosing now) and 
> haven't got much further on testing it there, although Jignesh is 
> already into performance testing.  Worked fine for demo purposes on 
> OSX.4, though, and I was able to import some old databases (Staffos, 
> TPCE) without unexpected issues.
> 
> Of course I would like to do a short beta, but I think we need to harass 
> people to test more.

Nothing motivates people to test more than moving toward RC1.  ;-)

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: Ready for beta2?

From
"Joshua D. Drake"
Date:
Bruce Momjian wrote:
> Josh Berkus wrote:
>> Bruce Momjian wrote:
>>> We have had very few beta1 issues.  I am thinking we should release
>>> beta2 next week and perhaps accelerate beta and consider a final release
>>> in November rather than December.  Because of the length of our feature
>>> freeze it is possible we are not going to have as many beta bugs.
>>>
>> Unfortunately, I think that's because people haven't been testing.  At 
>> my keynote at the PostgreSQL Fall Conference yesterday, I asked the 
>> audience of 63 people how many had built 8.3 beta and tried to run 
>> something on it ... 3.  And these are our enthusiasts.
>>
>> For me, I ran into a CC compile issues on Solaris (diagnosing now) and 
>> haven't got much further on testing it there, although Jignesh is 
>> already into performance testing.  Worked fine for demo purposes on 
>> OSX.4, though, and I was able to import some old databases (Staffos, 
>> TPCE) without unexpected issues.
>>
>> Of course I would like to do a short beta, but I think we need to harass 
>> people to test more.
> 
> Nothing motivates people to test more than moving toward RC1.  ;-)
> 

Getting Beta2 out is vital to actually getting people to test there are 
known issues and changes with Beta1 that have made it pretty much a 
useless Beta.

Sincerely,

Joshua D. Drake




Re: Ready for beta2?

From
Tom Lane
Date:
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Bruce Momjian wrote:
>> Nothing motivates people to test more than moving toward RC1.  ;-)

> Getting Beta2 out is vital to actually getting people to test there are 
> known issues and changes with Beta1 that have made it pretty much a 
> useless Beta.

Agreed --- at this point we know we've forced initdb, plus there are
those known locale issues on Windows, so it's a bit hard to ask someone
to install beta1 if they haven't already.  I think what we need to do
next is get to closure on the open issues and get a beta2 out ASAP.

I've posted notes over the past few days about half a dozen relatively-
minor-but-none-the-less-initdb-forcing issues in tsearch.  We have to
either fix those or decide we're not going to fix them.  I'm a bit
annoyed that Oleg and Teodor haven't responded to any of those comments.

I'm also not totally clear on whether we are happy with the Windows
locale situation yet.  Comments from the Win32 contingent?

Can anyone think of any other issues that should be considered beta2
stoppers?  (No, the contrib documentation isn't one...)
        regards, tom lane


Re: Ready for beta2?

From
"Marc G. Fournier"
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



- --On Sunday, October 21, 2007 22:38:04 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

> I've posted notes over the past few days about half a dozen relatively-
> minor-but-none-the-less-initdb-forcing issues in tsearch.  We have to
> either fix those or decide we're not going to fix them.  I'm a bit
> annoyed that Oleg and Teodor haven't responded to any of those comments.

Remove the tsearch2 stuff if we can't even get feedback from the developers at 
such a critical time?

- ----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHHCqo4QvfyHIvDvMRAjoYAJ9h0wSieG/NGKIVjxs5yEw3BEifrwCffGv6
A8oeYWF3Ophv+RwD2dWzgLw=
=tuCo
-----END PGP SIGNATURE-----



Re: Ready for beta2?

From
Tom Lane
Date:
"Marc G. Fournier" <scrappy@hub.org> writes:
> On Sunday, October 21, 2007 22:38:04 -0400 Tom Lane <tgl@sss.pgh.pa.us>
> wrote:
>> I've posted notes over the past few days about half a dozen relatively-
>> minor-but-none-the-less-initdb-forcing issues in tsearch.  We have to
>> either fix those or decide we're not going to fix them.  I'm a bit
>> annoyed that Oleg and Teodor haven't responded to any of those comments.

> Remove the tsearch2 stuff if we can't even get feedback from the developers at 
> such a critical time?

I don't want to go that far.  But I will start making changes on my own
authority if I don't hear objections pretty soon ...
        regards, tom lane


Re: Ready for beta2?

From
"Pavel Stehule"
Date:
>
> - --On Sunday, October 21, 2007 22:38:04 -0400 Tom Lane <tgl@sss.pgh.pa.us>
> wrote:
>
> > I've posted notes over the past few days about half a dozen relatively-
> > minor-but-none-the-less-initdb-forcing issues in tsearch.  We have to
> > either fix those or decide we're not going to fix them.  I'm a bit
> > annoyed that Oleg and Teodor haven't responded to any of those comments.
>
> Remove the tsearch2 stuff if we can't even get feedback from the developers at
> such a critical time?
>

It's little bit hard. TSearch2 was strongly refactorised by Tom, and
current Tom's questions are practical, but not fundamental.

Pavel


Re: Ready for beta2?

From
Dave Page
Date:
Tom Lane wrote:
> I'm also not totally clear on whether we are happy with the Windows
> locale situation yet.  Comments from the Win32 contingent?

I'm happy that UTF-8 support is now working again, but not happy that
initdb and pg_control will report (for example) "English_United
Kingdom.1252" despite my cluster being in UTF-8, not WIN1252. It seems
that's always been the case though, just that noone pointed it out before.

From chatting with Magnus, I believe he'd support losing the .1252 or
leaving it as is, where I'd rather rewrite it to .65001 (which he does
not support).

This is a cosmetic issue of course.

/D


Re: Ready for beta2?

From
Magnus Hagander
Date:
On Mon, Oct 22, 2007 at 08:59:07AM +0100, Dave Page wrote:
> Tom Lane wrote:
> > I'm also not totally clear on whether we are happy with the Windows
> > locale situation yet.  Comments from the Win32 contingent?
> 
> I'm happy that UTF-8 support is now working again, but not happy that
> initdb and pg_control will report (for example) "English_United
> Kingdom.1252" despite my cluster being in UTF-8, not WIN1252. It seems
> that's always been the case though, just that noone pointed it out before.

Bah, Dave beat me to it by a minute or two. But yes, that's the one thing
that I can see is still there. And yes, it's always been that way.


> From chatting with Magnus, I believe he'd support losing the .1252 or
> leaving it as is, where I'd rather rewrite it to .65001 (which he does
> not support).

I'm not against stripping the .1252 part, but I don't know what the clean
way to do that is, unless we want to drop it for all locales (which may or
may not be a good thing).

I specifically don't support rewriting it to .65001, becase that will
generate a locale name that's not valid. The same argument about clean way
applies here :-)

> This is a cosmetic issue of course.

Agreed.

//Magnus


Re: Ready for beta2?

From
Oleg Bartunov
Date:
On Mon, 22 Oct 2007, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@hub.org> writes:
>> On Sunday, October 21, 2007 22:38:04 -0400 Tom Lane <tgl@sss.pgh.pa.us>
>> wrote:
>>> I've posted notes over the past few days about half a dozen relatively-
>>> minor-but-none-the-less-initdb-forcing issues in tsearch.  We have to
>>> either fix those or decide we're not going to fix them.  I'm a bit
>>> annoyed that Oleg and Teodor haven't responded to any of those comments.
>
>> Remove the tsearch2 stuff if we can't even get feedback from the developers at
>> such a critical time?
>
> I don't want to go that far.  But I will start making changes on my own
> authority if I don't hear objections pretty soon ...
>

I and Teodor are really busy working on other project(s) and it's very 
difficult for us to switch our attention. Personally, I don't see any
principal quiestion where hackers community wouldn't think better than
we did and I rely on you, our colleagues.

The only concern is about changes of parser's token type, but I'm not 
ready to say more than just concern :)

ts_debug is a really debug function and could be changed. Btw, it 
doesn't supports thesaurus dictionaries, so it should be rewritten in C.

I have rather slow connection right now,  Teodor, probably, will
comment in more details.

Sorry, guys, for delay and thank you for understanding.



>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
>
    Regards,        Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83


Re: Ready for beta2?

From
Gregory Stark
Date:
"Oleg Bartunov" <oleg@sai.msu.su> writes:

> ts_debug is a really debug function and could be changed. Btw, it doesn't
> supports thesaurus dictionaries, so it should be rewritten in C.

I would think things like ts_debug (and ts_stat?) which are handy support
modules but not fundamentally part of the tsearch api itself should just be
left outside of core in a contrib module so they can be fiddled with in
subsequent releases.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


Re: Ready for beta2?

From
"Pavel Stehule"
Date:
2007/10/22, Gregory Stark <stark@enterprisedb.com>:
> "Oleg Bartunov" <oleg@sai.msu.su> writes:
>
> > ts_debug is a really debug function and could be changed. Btw, it doesn't
> > supports thesaurus dictionaries, so it should be rewritten in C.
>
> I would think things like ts_debug (and ts_stat?) which are handy support
> modules but not fundamentally part of the tsearch api itself should just be
> left outside of core in a contrib module so they can be fiddled with in
> subsequent releases.
>

ts_debug is usefull for teting of some configuration like czech.
ts_stat is little bit experimental, but ts_debug is usefull and
necessary.

Pavel


> --
>   Gregory Stark
>   EnterpriseDB          http://www.enterprisedb.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>


Re: Ready for beta2?

From
"Merlin Moncure"
Date:
On 10/21/07, Josh Berkus <josh@agliodbs.com> wrote:
> Bruce Momjian wrote:
> > We have had very few beta1 issues.  I am thinking we should release
> > beta2 next week and perhaps accelerate beta and consider a final release
> > in November rather than December.  Because of the length of our feature
> > freeze it is possible we are not going to have as many beta bugs.
> >
>
> Unfortunately, I think that's because people haven't been testing.  At
> my keynote at the PostgreSQL Fall Conference yesterday, I asked the
> audience of 63 people how many had built 8.3 beta and tried to run
> something on it ... 3.  And these are our enthusiasts.

I've been beating on the database throughout the development cycle and
on the beta.  I haven't tested some particular features like the new
tsearch stuff but have done a lot of stress testing.  The stability of
the database has been really remarkable.

Since there is a catalog bump my suggestion would be to wrap beta2
asap...hopefully that will be the last one.  wrt moving to RC1 and
beyond, it's looking good to me...give me a heads up if you are
looking for testing in particular areas.

merlin


Re: Ready for beta2?

From
Robert Treat
Date:
On Sunday 21 October 2007 22:38, Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > Bruce Momjian wrote:
> >> Nothing motivates people to test more than moving toward RC1.  ;-)
> >
> > Getting Beta2 out is vital to actually getting people to test there are
> > known issues and changes with Beta1 that have made it pretty much a
> > useless Beta.
>
> Agreed --- at this point we know we've forced initdb, plus there are
> those known locale issues on Windows, so it's a bit hard to ask someone
> to install beta1 if they haven't already.  I think what we need to do
> next is get to closure on the open issues and get a beta2 out ASAP.
<snip>
> Can anyone think of any other issues that should be considered beta2
> stoppers?  (No, the contrib documentation isn't one...)
>

There was talk that the txid contrib module could be folded into core should 
we do an initdb post beta; has that idea been revisted now that we have?  

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL


Re: Ready for beta2?

From
Magnus Hagander
Date:
On Mon, Oct 22, 2007 at 09:25:03AM -0400, Robert Treat wrote:
> On Sunday 21 October 2007 22:38, Tom Lane wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> > > Bruce Momjian wrote:
> > >> Nothing motivates people to test more than moving toward RC1.  ;-)
> > >
> > > Getting Beta2 out is vital to actually getting people to test there are
> > > known issues and changes with Beta1 that have made it pretty much a
> > > useless Beta.
> >
> > Agreed --- at this point we know we've forced initdb, plus there are
> > those known locale issues on Windows, so it's a bit hard to ask someone
> > to install beta1 if they haven't already.  I think what we need to do
> > next is get to closure on the open issues and get a beta2 out ASAP.
> <snip>
> > Can anyone think of any other issues that should be considered beta2
> > stoppers?  (No, the contrib documentation isn't one...)
> >
> 
> There was talk that the txid contrib module could be folded into core should 
> we do an initdb post beta; has that idea been revisted now that we have?  

Yes. It has been folded in.
http://archives.postgresql.org/pgsql-committers/2007-10/msg00246.php


//Magnus


Re: Ready for beta2?

From
Tom Lane
Date:
Magnus Hagander <magnus@hagander.net> writes:
> On Mon, Oct 22, 2007 at 08:59:07AM +0100, Dave Page wrote:
>> From chatting with Magnus, I believe he'd support losing the .1252 or
>> leaving it as is, where I'd rather rewrite it to .65001 (which he does
>> not support).

> I'm not against stripping the .1252 part, but I don't know what the clean
> way to do that is, unless we want to drop it for all locales (which may or
> may not be a good thing).

Why not "if selected encoding is UTF8, drop any .nnn part"?
(Inside #ifdef WIN32 of course.)
        regards, tom lane


Re: Ready for beta2?

From
Dimitri Fontaine
Date:
Le lundi 22 octobre 2007, Robert Treat a écrit :
> There was talk that the txid contrib module could be folded into core
> should we do an initdb post beta; has that idea been revisted now that we
> have?

It very well seem to have been integrated into core:
http://repo.or.cz/w/PostgreSQL.git?a=commit;h=5d54ea7722406d55078b735fa420d474bee8cafb

Regards,
--
dim

Re: Ready for beta2?

From
Dave Page
Date:
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Mon, Oct 22, 2007 at 08:59:07AM +0100, Dave Page wrote:
>>> From chatting with Magnus, I believe he'd support losing the .1252 or
>>> leaving it as is, where I'd rather rewrite it to .65001 (which he does
>>> not support).
> 
>> I'm not against stripping the .1252 part, but I don't know what the clean
>> way to do that is, unless we want to drop it for all locales (which may or
>> may not be a good thing).
> 
> Why not "if selected encoding is UTF8, drop any .nnn part"?
> (Inside #ifdef WIN32 of course.)

Consistency? It is better than the current situation though I agree.

Regards, Dave


Re: Ready for beta2?

From
Magnus Hagander
Date:
On Mon, Oct 22, 2007 at 03:18:38PM +0100, Dave Page wrote:
> Tom Lane wrote:
> > Magnus Hagander <magnus@hagander.net> writes:
> >> On Mon, Oct 22, 2007 at 08:59:07AM +0100, Dave Page wrote:
> >>> From chatting with Magnus, I believe he'd support losing the .1252 or
> >>> leaving it as is, where I'd rather rewrite it to .65001 (which he does
> >>> not support).
> > 
> >> I'm not against stripping the .1252 part, but I don't know what the clean
> >> way to do that is, unless we want to drop it for all locales (which may or
> >> may not be a good thing).
> > 
> > Why not "if selected encoding is UTF8, drop any .nnn part"?
> > (Inside #ifdef WIN32 of course.)
> 
> Consistency? It is better than the current situation though I agree.

As I chatted with Dave about - wnat encoding? We pull that value cluster
wide, but the encoding is per-database. You could have one UTF8 and one
WIN1252 database...

//Magnus


Re: Ready for beta2?

From
Tom Lane
Date:
Magnus Hagander <magnus@hagander.net> writes:
> As I chatted with Dave about - wnat encoding? We pull that value cluster
> wide, but the encoding is per-database. You could have one UTF8 and one
> WIN1252 database...

Will chklocale.c actually allow that?  Should it?  We've spent a lot of
time zeroed in on initdb's behavior, but the other piece of the puzzle
is which DB encodings should CREATE DATABASE allow afterwards.  It
sounds to me that Windows may be more flexible than the standard Unix
locale support on this point, but I'm not sure how much more flexible.

There's also the question of how we make sure that strings returned
by the OS (eg strerror) are in the DB's encoding.  I think that the
Unix side is not fully up to speed on that either --- we don't try
to prevent you from setting, eg, LC_MESSAGES = foo.utf8 when LC_CTYPE
and the DB encoding are iso88591.  I've thought about trying to enforce
that the encoding-suffix-if-any is the same as LC_CTYPE's for all the LC_
values, but I'm not sure whether that approach is sane for Windows.
        regards, tom lane


Re: Ready for beta2?

From
Magnus Hagander
Date:
On Mon, Oct 22, 2007 at 10:55:14AM -0400, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > As I chatted with Dave about - wnat encoding? We pull that value cluster
> > wide, but the encoding is per-database. You could have one UTF8 and one
> > WIN1252 database...
> 
> Will chklocale.c actually allow that?  Should it?  We've spent a lot of
> time zeroed in on initdb's behavior, but the other piece of the puzzle
> is which DB encodings should CREATE DATABASE allow afterwards.  It
> sounds to me that Windows may be more flexible than the standard Unix
> locale support on this point, but I'm not sure how much more flexible.

Yes, if I pick the proper locale, it does work. 

FOr example, I can properly initdb in UTF8 and then create a WIN1252
database.


> There's also the question of how we make sure that strings returned
> by the OS (eg strerror) are in the DB's encoding.  I think that the
> Unix side is not fully up to speed on that either --- we don't try
> to prevent you from setting, eg, LC_MESSAGES = foo.utf8 when LC_CTYPE
> and the DB encoding are iso88591.  I've thought about trying to enforce
> that the encoding-suffix-if-any is the same as LC_CTYPE's for all the LC_
> values, but I'm not sure whether that approach is sane for Windows.

That's a potential problem - I assume you'll have the same problem as on 
Unix if you say your db is in UTF8 buy your messages are in LATIN1.

//Magnus


Re: Ready for beta2?

From
"Joshua D. Drake"
Date:
On Mon, 22 Oct 2007 12:07:06 +0100
Gregory Stark <stark@enterprisedb.com> wrote:

> "Oleg Bartunov" <oleg@sai.msu.su> writes:
>
> > ts_debug is a really debug function and could be changed. Btw, it
> > doesn't supports thesaurus dictionaries, so it should be rewritten
> > in C.
>
> I would think things like ts_debug (and ts_stat?) which are handy
> support modules but not fundamentally part of the tsearch api itself
> should just be left outside of core in a contrib module so they can
> be fiddled with in subsequent releases.

I would prefer not to do that. It is quite obnoxious to have to go
"somewhere else" to get support functions.

Joshua D. Drake


--
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/        UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/