RC1 blocker issues

I wrote:

* possible rearrangement of pg_stat column order:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00643.php
Should we do this, and if so should we force initdb (via a catversion
change)? I'm currently leaning to the thought that if we change it
we should force initdb, else we'll risk having a noticeable user-visible
difference between different "8.2" installations.

Actually, on looking closer, we *must* force initdb because this changes
the expected output for the rules regression test.

So, yea or nay? I'm working up the patch right now, but will hold off
applying until I hear some comments.

regards, tom lane

Tom Lane wrote:

* Brendan Jurd's recent report about from_char/to_char not being
consistent about 'D':
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00226.php
Is this a bug? If so I think we should fix it now.

Should be fixed, unless someone with Oracle can show that it is
intentional.

* the to_char month/day name localization issue. Consensus at the
moment seems to be that we should revert the last-minute patch.

Leave for 8.3.

* possible rearrangement of pg_stat column order:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00643.php
Should we do this, and if so should we force initdb (via a catversion
change)? I'm currently leaning to the thought that if we change it
we should force initdb, else we'll risk having a noticeable
user-visible difference between different "8.2" installations.

Fix and initdb.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Fri, Nov 24, 2006 at 02:48:22PM -0500, Tom Lane wrote:

I wrote:

* possible rearrangement of pg_stat column order:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00643.php
Should we do this, and if so should we force initdb (via a
catversion change)? I'm currently leaning to the thought that if
we change it we should force initdb, else we'll risk having a
noticeable user-visible difference between different "8.2"
installations.

Actually, on looking closer, we *must* force initdb because this
changes the expected output for the rules regression test.

So, yea or nay? I'm working up the patch right now, but will hold
off applying until I hear some comments.

+1 on applying it. Beta testers should understand what "beta" and
"test" mean. :)

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

* the to_char month/day name localization issue. Consensus at the
moment seems to be that we should revert the last-minute patch.

Leave for 8.3.

Uh, you mean leave the patch in? I thought you wanted it out.

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

* the to_char month/day name localization issue. Consensus at the
moment seems to be that we should revert the last-minute patch.

Leave for 8.3.

Uh, you mean leave the patch in? I thought you wanted it out.

I assume he means leave the change for 8.3, not now.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

* the to_char month/day name localization issue. Consensus at the
moment seems to be that we should revert the last-minute patch.

Leave for 8.3.

Uh, you mean leave the patch in? I thought you wanted it out.

Sorry, take the patch out but leave the issue pending for 8.3.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Fri, 2006-11-24 at 12:37 -0800, David Fetter wrote:

On Fri, Nov 24, 2006 at 02:48:22PM -0500, Tom Lane wrote:

I wrote:

* possible rearrangement of pg_stat column order:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00643.php
Should we do this, and if so should we force initdb (via a
catversion change)? I'm currently leaning to the thought that if
we change it we should force initdb, else we'll risk having a
noticeable user-visible difference between different "8.2"
installations.

Actually, on looking closer, we *must* force initdb because this
changes the expected output for the rules regression test.

So, yea or nay? I'm working up the patch right now, but will hold
off applying until I hear some comments.

+1 on applying it. Beta testers should understand what "beta" and
"test" mean. :)

Yes, I would like to rearrange the columns.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

Tom Lane wrote:

I wrote:

* possible rearrangement of pg_stat column order:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00643.php
Should we do this, and if so should we force initdb (via a catversion
change)? I'm currently leaning to the thought that if we change it
we should force initdb, else we'll risk having a noticeable user-visible
difference between different "8.2" installations.

Actually, on looking closer, we *must* force initdb because this changes
the expected output for the rules regression test.

So, yea or nay? I'm working up the patch right now, but will hold off
applying until I hear some comments.

Fixing it later would be nastier, or impossible. I think we should fix it
now. We don't have an absolute promise not to require an initdb during
beta, do we?

cheers

andrew

Peter Eisentraut wrote:

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

* the to_char month/day name localization issue. Consensus at the
moment seems to be that we should revert the last-minute patch.

Leave for 8.3.

Uh, you mean leave the patch in? I thought you wanted it out.

Sorry, take the patch out but leave the issue pending for 8.3.

OK, patch reverted.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:

I wrote:

* possible rearrangement of pg_stat column order:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00643.php
Should we do this, and if so should we force initdb (via a catversion
change)? I'm currently leaning to the thought that if we change it
we should force initdb, else we'll risk having a noticeable user-visible
difference between different "8.2" installations.

Actually, on looking closer, we *must* force initdb because this changes
the expected output for the rules regression test.

So, yea or nay? I'm working up the patch right now, but will hold off
applying until I hear some comments.

I would like to see it changed - even late into the beta cycle ...

Stefan

BTW, if we do change system_views.sql I'm inclined to remove the hack
for pg_stat_file() at the bottom, and instead fix pg_proc.h --- initdb
can handle this properly now.

There is no reason to rush the release of 8.2, if there are last minute
-- known items. We should fix them. Being a month late, but having a
better product, is always a better solution.

Sincerely,

Joshua D. Drake

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Saturday, November 25, 2006 11:00:04 -0800 "Joshua D. Drake"
<jd@commandprompt.com> wrote:

BTW, if we do change system_views.sql I'm inclined to remove the hack
for pg_stat_file() at the bottom, and instead fix pg_proc.h --- initdb
can handle this properly now.

There is no reason to rush the release of 8.2, if there are last minute --
known items. We should fix them. Being a month late, but having a better
product, is always a better solution.

As rare as he and I agree ... I agree ... LISA is nice and all, but end product
*is* more important then timing, unless you are Microsoft, of course :)

- ----
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 v1.4.5 (FreeBSD)

iD8DBQFFaJlE4QvfyHIvDvMRAhatAKCeumY3DPTmULzSplGWlXR+00qEBwCfUFUz
rI3THgwtRBzvh/JEBBGlrtk=
=/m9d
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:

- --On Saturday, November 25, 2006 11:00:04 -0800 "Joshua D. Drake"
<jd@commandprompt.com> wrote:

As rare as he and I agree ... I agree

Wow - you wanna go lie down for a while?

:-p

Regards, Dave.

Dave Page wrote:

Marc G. Fournier wrote:

- --On Saturday, November 25, 2006 11:00:04 -0800 "Joshua D. Drake"
<jd@commandprompt.com> wrote:

As rare as he and I agree ... I agree

Wow - you wanna go lie down for a while?

Oh come on... it isn't *that* rare ;)

Joshua D. Drake

"Marc G. Fournier" <scrappy@hub.org> writes:

As rare as he and I agree ... I agree ... LISA is nice and all, but
end product *is* more important then timing, unless you are Microsoft,
of course :)

I'm not concerned about announcing at LISA (though I know Josh is) ...
but at the same time I want to get the thing out the door. I'm not sure
that anything will be gained by further delay.

This has been sort of a weird beta period, because it's the first one
we've had where cleaning up portability problems has been a complete
non-issue. The buildfarm has changed the rules of the game that way.
Previously we've always had to allocate a fair amount of time for
getting and dealing with port reports, but I don't think we need to
do that anymore. So really the release decision is down to "at what
point do we think it's stable enough to call it a release?".

I think we're at that point already: I just looked through the CVS logs,
and by my count there were 40 non-cosmetic patches applied to the main
source tree (not doc/ or contrib/) during the past month. Of these
all but three either were or could have been applied to 8.1 as well,
ie, they fixed problems that exist in 8.1 or before. The three actual
new-in-8.2 bugs found in the last thirty days are:

2006-11-10 13:10 tgl

	* backend/catalog/information_schema.sql: Fix errors in
	key_column_usage.position_in_unique_constraint column recently
	added to information_schema (per a SQL2003 addition).  The original
	coding failed if a referenced column participated in more than one
	pg_constraint entry.  Also, it did not work if an FK relied
	directly on a unique index without any constraint syntactic sugar
	--- this case is outside the SQL spec, but PG has always supported
	it, so it's reasonable for our information_schema to handle it too.
	Per bug#2750 from Stephen Haberman.

2006-11-10 17:59 tgl

* backend/utils/adt/ruleutils.c: Fix pg_get_serial_sequence(),
which could incorrectly return the name of an index on a serial
column, rather than the name of the associated sequence. Fallout
from recent changes in dependency setup for serials. Per bug #2732
from Basil Evseenko.

2006-11-24 16:18 tgl

* backend/catalog/system_views.sql, backend/utils/adt/genfile.c,
include/catalog/catversion.h, include/catalog/pg_proc.h,
test/regress/expected/rules.out: Change pg_stat_all_tables and
sister views to put the recently-added vacuum/analyze timestamp
columns at the end, rather than at a random spot in the middle as
in the original patch.

That last one barely even qualifies as a bug; it's a cosmetic
improvement. So it's now a solid two weeks since we found a real new bug.

So if you ask me, we are past the point of diminishing returns for the
current level of testing. Putting out an RC might draw the attention of
a few more people, but really the only way we are going to find more
bugs is to put out a release. Or perhaps knock heads together a little
harder on pgsql-hackers to make people think less about 8.3 development
and more about 8.2 testing, but how successful is that likely to be?

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Saturday, November 25, 2006 15:58:41 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

So if you ask me, we are past the point of diminishing returns for the
current level of testing. Putting out an RC might draw the attention of
a few more people, but really the only way we are going to find more
bugs is to put out a release. Or perhaps knock heads together a little
harder on pgsql-hackers to make people think less about 8.3 development
and more about 8.2 testing, but how successful is that likely to be?

Based on experience ... not very. And I'm not voicing against LISA, I'm just
agreeing with Joshua that it shouldn't the "requirement" ... if we are ready,
no arguments from this end ...

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 v1.4.5 (FreeBSD)

iD8DBQFFaLC44QvfyHIvDvMRAnO3AKCJy+ghmE4dLk1/jQ0jWEw+ySbWJgCfeFlB
928t3jXtaKIgwE+GSSigU1g=
=mVks
-----END PGP SIGNATURE-----

On Sat, Nov 25, 2006 at 03:58:41PM -0500, Tom Lane wrote:

source tree (not doc/ or contrib/) during the past month. Of these
all but three either were or could have been applied to 8.1 as well,
ie, they fixed problems that exist in 8.1 or before. The three actual

It strikes me that this sort of analysis might be a useful future
rule of thumb test for releases, given the buildfarm, no? At what
point does the reported-bug testing stop, by some overwhelming
margin, revealing new bugs? That's the proof that a release
candidate is reached.

Andrew "process high horse is about to throw me" Sullivan

--
Andrew Sullivan | ajs@crankycanuck.ca
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
--Alexander Hamilton

Tom Lane wrote:

This has been sort of a weird beta period, because it's the first one
we've had where cleaning up portability problems has been a complete
non-issue. The buildfarm has changed the rules of the game that way.
Previously we've always had to allocate a fair amount of time for
getting and dealing with port reports, but I don't think we need to
do that anymore.

Isn't it nice when one's children outperform the intentions,
expectations and hopes one held for them? ;-)

cheers

andrew

Marc, Josh:

There is no reason to rush the release of 8.2, if there are last minute
-- known items. We should fix them. Being a month late, but having a
better product, is always a better solution.

As rare as he and I agree ... I agree ... LISA is nice and all, but end
product *is* more important then timing, unless you are Microsoft, of
course :)

Just so you all know: I gave a green flag for two magazines (one in Middle
East, one in Dutch) to carry articles about 8.2 for their January issues,
which will come out in December. So there's a distinct possibility that
those magazines will come out and 8.2 still won't be available. I hadn't
anticipated us slipping the schedule by more than a month. Not that this
should be our deciding criteria, but just so people know that I'm not just
pushing the date for no reason.

Also note that if we release between December 18th and January 3rd, we can
pretty much expect no coverage from the press.

Overall, I submit that our release process is broken, and that we're having
trouble getting this release out because nobody is paying attention to it (of
which I too have been guilty off-and-on). I suggest that we need something
different for 8.3, or we can forget about even trying to do a short release
schedule.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco