Обсуждение: Ready for beta2?
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. +
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
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
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
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. +
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
"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
-----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-----
"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
> > - --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
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
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
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
"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
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 >
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
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
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
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
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
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
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
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
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
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/