v7.2b3 packaged, but not announced beyond here yet ...
Okay, PeterE got the appropriate scripts setup, and I just ran the
packaging script, which appears to have all gone great ...
As usual, I want to give it ~24hrs to perculate through the mirrors before
doing a larger announce, but if anyone would like to take a quick test
through and make sure the packaging isn't missing anything, the tar files
are avaialble at:
ftp://ftp.postgresql.org/pub/beta
Let us know if there are any problems and we'll re-package as appropriate
...
"Marc G. Fournier" <scrappy@hub.org> writes:
if anyone would like to take a quick test
through and make sure the packaging isn't missing anything, the tar files
are avaialble at:
ftp://ftp.postgresql.org/pub/beta
Why do all the CVS $Header$ lines in this tarball look like
$Header: /projects/cvsroot/pgsql/GNUmakefile.in,v 1.23 2001/11/21 23:19:25 momjian Exp $
and not
$Header: /cvsroot/pgsql/GNUmakefile.in,v 1.23 2001/11/21 23:19:25 momjian Exp $
which is what I see in CVS checkout (as well as earlier beta tarballs)?
This makes it *real* painful to diff the tarball against my local
checkout, which is what I usually do to validate a tarball.
I think it might be okay other than that, but it's hard to tell...
regards, tom lane
"Marc G. Fournier" <scrappy@hub.org> writes:
if anyone would like to take a quick test
through and make sure the packaging isn't missing anything, the tar files
are avaialble at:
ftp://ftp.postgresql.org/pub/betaWhy do all the CVS $Header$ lines in this tarball look like
$Header: /projects/cvsroot/pgsql/GNUmakefile.in,v 1.23 2001/11/21 23:19:25 momjian Exp $
and not
$Header: /cvsroot/pgsql/GNUmakefile.in,v 1.23 2001/11/21 23:19:25 momjian Exp $
which is what I see in CVS checkout (as well as earlier beta tarballs)?
This makes it *real* painful to diff the tarball against my local
checkout, which is what I usually do to validate a tarball.I think it might be okay other than that, but it's hard to tell...
For some strange reason, anoncvs uses /projects/cvsroot while committers
cvs uses just /cvsroot. I am sure the problem is that he is pulling
from anoncvs and not from cvs. My guess is that you will have to pull
out $header lines before doing the diff. Yes, a pain.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026I know what the problem is, and am currently working on getting it fixed,
right Vince? :)
On Thu, 22 Nov 2001, Tom Lane wrote:
Show quoted text
"Marc G. Fournier" <scrappy@hub.org> writes:
if anyone would like to take a quick test
through and make sure the packaging isn't missing anything, the tar files
are avaialble at:
ftp://ftp.postgresql.org/pub/betaWhy do all the CVS $Header$ lines in this tarball look like
$Header: /projects/cvsroot/pgsql/GNUmakefile.in,v 1.23 2001/11/21 23:19:25 momjian Exp $
and not
$Header: /cvsroot/pgsql/GNUmakefile.in,v 1.23 2001/11/21 23:19:25 momjian Exp $
which is what I see in CVS checkout (as well as earlier beta tarballs)?
This makes it *real* painful to diff the tarball against my local
checkout, which is what I usually do to validate a tarball.I think it might be okay other than that, but it's hard to tell...
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I am sure the problem is that he is pulling
from anoncvs and not from cvs.
If so, could I request that future tarballs be pulled from logged-in
cvs? It's unlikely that anybody but the committers circle will do
such diffing, so you may as well make it easier for us rather than
other people.
(Actually an even better answer would be to make anoncvs and committers
cvs show the same path, but if that's not practical I won't argue.)
regards, tom lane
On Thursday 22 November 2001 12:57 pm, Marc G. Fournier wrote:
As usual, I want to give it ~24hrs to perculate through the mirrors before
doing a larger announce, but if anyone would like to take a quick test
through and make sure the packaging isn't missing anything, the tar files
are avaialble at:
ftp://ftp.postgresql.org/pub/beta
Let us know if there are any problems and we'll re-package as appropriate
[back on-list]
After much help from Marc, and a good tarball (apparently), we have RPMs.
Regression does the expected thing on RedHat 7.2 (locale settings prevent a
complete PASS -- the diffs are attached for those who are curious).
RPMs for testing are at
ftp.postgresql.org/pub/binary/beta/RPMS/{SRPMS|redhat-7.2}
Many thanks to Marc and PeterE for the man pages and the html docs being
built again, and a special thank you to Peter for the initial patchset that
allowed a smooth build relatively quickly. Oh, and Marc, the man pages and
the html docs ARE being built properly for the RPMset's consumption.
Please test this RPMset if you do RPM work, but also consider them BETA.
That of course means that 'rpm -Fvh' on your production server is not
recommended.
Be sure, if upgrading, to dump out your whole database system first, as the
migration tools are a little finicky. This is, after all, a major version
upgrade.
I'll make a more public announcement after Marc makes a more public 7.2b3
announcement.
Developers who are a member of group 'pgsql' on cvs.postgresql.org and who
want to build RPMsets for other distributions/architectures, feel free to do
so and upload into that tree, setting up your own subdir. Group write is and
should be set appropriately. Yes, Thomas, that means you and Mandrake
whichever you're running. :-)
Others who wish to build RPMs for non-redhat-7.2 architectures, contact me
off-list with locations and details.
Note that due to the possibility of third-party Trojan RPMsets, those who can
rebuild from the src rpm should do so for testing. Signed binary RPMs for
distributions will likely be generated by those distributors once we have a
final release. I will also likely sign a final RPM release, with my public
key being available on the ftp site.
Enjoy! (If I sound cheery, well, there's some sort of chemical in turkey meat
that, if consumed in a large enough quantity, makes you very cheerful --
almost jolly. :-)).
And, as today is Thanksgiving in the 'States, I'll just add to this
announcement my THANK YOU to all the developers, contributors, testers, and
users of this magnificent RDBMS we call PostgreSQL.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Attachments:
regression.diffstext/x-diff; charset=iso-8859-1; name=regression.diffsDownload
*** ./expected/char.out Mon May 21 12:54:46 2001
--- ./results/char.out Thu Nov 22 22:15:30 2001
***************
*** 63,74 ****
WHERE c.f1 < 'a';
five | f1
------+----
- | A
| 1
| 2
| 3
|
! (5 rows)
SELECT '' AS six, c.*
FROM CHAR_TBL c
--- 63,73 ----
WHERE c.f1 < 'a';
five | f1
------+----
| 1
| 2
| 3
|
! (4 rows)
SELECT '' AS six, c.*
FROM CHAR_TBL c
***************
*** 76,95 ****
six | f1
-----+----
| a
- | A
| 1
| 2
| 3
|
! (6 rows)
SELECT '' AS one, c.*
FROM CHAR_TBL c
WHERE c.f1 > 'a';
one | f1
-----+----
| c
! (1 row)
SELECT '' AS two, c.*
FROM CHAR_TBL c
--- 75,94 ----
six | f1
-----+----
| a
| 1
| 2
| 3
|
! (5 rows)
SELECT '' AS one, c.*
FROM CHAR_TBL c
WHERE c.f1 > 'a';
one | f1
-----+----
+ | A
| c
! (2 rows)
SELECT '' AS two, c.*
FROM CHAR_TBL c
***************
*** 97,104 ****
two | f1
-----+----
| a
| c
! (2 rows)
DROP TABLE CHAR_TBL;
--
--- 96,104 ----
two | f1
-----+----
| a
+ | A
| c
! (3 rows)
DROP TABLE CHAR_TBL;
--
======================================================================
*** ./expected/varchar.out Mon May 21 12:54:46 2001
--- ./results/varchar.out Thu Nov 22 22:15:30 2001
***************
*** 52,63 ****
WHERE c.f1 < 'a';
five | f1
------+----
- | A
| 1
| 2
| 3
|
! (5 rows)
SELECT '' AS six, c.*
FROM VARCHAR_TBL c
--- 52,62 ----
WHERE c.f1 < 'a';
five | f1
------+----
| 1
| 2
| 3
|
! (4 rows)
SELECT '' AS six, c.*
FROM VARCHAR_TBL c
***************
*** 65,84 ****
six | f1
-----+----
| a
- | A
| 1
| 2
| 3
|
! (6 rows)
SELECT '' AS one, c.*
FROM VARCHAR_TBL c
WHERE c.f1 > 'a';
one | f1
-----+----
| c
! (1 row)
SELECT '' AS two, c.*
FROM VARCHAR_TBL c
--- 64,83 ----
six | f1
-----+----
| a
| 1
| 2
| 3
|
! (5 rows)
SELECT '' AS one, c.*
FROM VARCHAR_TBL c
WHERE c.f1 > 'a';
one | f1
-----+----
+ | A
| c
! (2 rows)
SELECT '' AS two, c.*
FROM VARCHAR_TBL c
***************
*** 86,93 ****
two | f1
-----+----
| a
| c
! (2 rows)
DROP TABLE VARCHAR_TBL;
--
--- 85,93 ----
two | f1
-----+----
| a
+ | A
| c
! (3 rows)
DROP TABLE VARCHAR_TBL;
--
======================================================================
*** ./expected/int8.out Fri Jan 26 17:50:26 2001
--- ./results/int8.out Thu Nov 22 22:15:29 2001
***************
*** 236,246 ****
SELECT '' AS to_char_13, to_char(q2, 'L9999999999999999.000') FROM INT8_TBL;
to_char_13 | to_char
------------+------------------------
! | 456.000
! | 4567890123456789.000
! | 123.000
! | 4567890123456789.000
! | -4567890123456789.000
(5 rows)
SELECT '' AS to_char_14, to_char(q2, 'FM9999999999999999.999') FROM INT8_TBL;
--- 236,246 ----
SELECT '' AS to_char_13, to_char(q2, 'L9999999999999999.000') FROM INT8_TBL;
to_char_13 | to_char
------------+------------------------
! | $ 456.000
! | $ 4567890123456789.000
! | $ 123.000
! | $ 4567890123456789.000
! | $-4567890123456789.000
(5 rows)
SELECT '' AS to_char_14, to_char(q2, 'FM9999999999999999.999') FROM INT8_TBL;
======================================================================
*** ./expected/numeric.out Fri Apr 7 15:17:42 2000
--- ./results/numeric.out Thu Nov 22 22:15:43 2001
***************
*** 928,943 ****
SELECT '' AS to_char_16, to_char(val, 'L9999999999999999.099999999999999') FROM num_data;
to_char_16 | to_char
------------+------------------------------------
! | .000000000000000
! | .000000000000000
! | -34338492.215397047000000
! | 4.310000000000000
! | 7799461.411900000000000
! | 16397.038491000000000
! | 93901.577630260000000
! | -83028485.000000000000000
! | 74881.000000000000000
! | -24926804.045047420000000
(10 rows)
SELECT '' AS to_char_17, to_char(val, 'FM9999999999999999.99999999999999') FROM num_data;
--- 928,943 ----
SELECT '' AS to_char_16, to_char(val, 'L9999999999999999.099999999999999') FROM num_data;
to_char_16 | to_char
------------+------------------------------------
! | $ .000000000000000
! | $ .000000000000000
! | $ -34338492.215397047000000
! | $ 4.310000000000000
! | $ 7799461.411900000000000
! | $ 16397.038491000000000
! | $ 93901.577630260000000
! | $ -83028485.000000000000000
! | $ 74881.000000000000000
! | $ -24926804.045047420000000
(10 rows)
SELECT '' AS to_char_17, to_char(val, 'FM9999999999999999.99999999999999') FROM num_data;
======================================================================
*** ./expected/geometry.out Fri Sep 28 03:59:52 2001
--- ./results/geometry.out Thu Nov 22 22:15:55 2001
***************
*** 127,133 ****
| (-5,-12) | [(10,-10),(-3,-4)] | (-1.60487804878049,-4.64390243902439)
| (10,10) | [(10,-10),(-3,-4)] | (2.39024390243902,-6.48780487804878)
| (0,0) | [(-1000000,200),(300000,-40)] | (0.0028402365895872,15.384614860264)
! | (-10,0) | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140473)
| (-3,4) | [(-1000000,200),(300000,-40)] | (-2.99789812267519,15.3851688427303)
| (5.1,34.5) | [(-1000000,200),(300000,-40)] | (5.09647083221496,15.3836744976925)
| (-5,-12) | [(-1000000,200),(300000,-40)] | (-4.99494420845634,15.3855375281616)
--- 127,133 ----
| (-5,-12) | [(10,-10),(-3,-4)] | (-1.60487804878049,-4.64390243902439)
| (10,10) | [(10,-10),(-3,-4)] | (2.39024390243902,-6.48780487804878)
| (0,0) | [(-1000000,200),(300000,-40)] | (0.0028402365895872,15.384614860264)
! | (-10,0) | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140472)
| (-3,4) | [(-1000000,200),(300000,-40)] | (-2.99789812267519,15.3851688427303)
| (5.1,34.5) | [(-1000000,200),(300000,-40)] | (5.09647083221496,15.3836744976925)
| (-5,-12) | [(-1000000,200),(300000,-40)] | (-4.99494420845634,15.3855375281616)
***************
*** 152,158 ****
| (2.12132034355964,2.12132034355964),(-2.12132034355964,-2.12132034355964)
| (71.7106781186548,72.7106781186548),(-69.7106781186548,-68.7106781186548)
| (4.53553390593274,6.53553390593274),(-2.53553390593274,-0.535533905932738)
! | (3.12132034355964,4.12132034355964),(-1.12132034355964,-0.121320343559642)
| (107.071067811865,207.071067811865),(92.9289321881345,192.928932188135)
| (170.710678118655,70.7106781186548),(29.2893218813452,-70.7106781186548)
(6 rows)
--- 152,158 ----
| (2.12132034355964,2.12132034355964),(-2.12132034355964,-2.12132034355964)
| (71.7106781186548,72.7106781186548),(-69.7106781186548,-68.7106781186548)
| (4.53553390593274,6.53553390593274),(-2.53553390593274,-0.535533905932738)
! | (3.12132034355964,4.12132034355964),(-1.12132034355964,-0.121320343559643)
| (107.071067811865,207.071067811865),(92.9289321881345,192.928932188135)
| (170.710678118655,70.7106781186548),(29.2893218813452,-70.7106781186548)
(6 rows)
***************
*** 504,510 ****
ORDER BY distance, circle, point using <<;
twentyfour | circle | point | distance
------------+----------------+------------+-------------------
! | <(100,0),100> | (5.1,34.5) | 0.976531926977965
| <(1,2),3> | (-3,4) | 1.47213595499958
| <(0,0),3> | (-3,4) | 2
| <(100,0),100> | (-3,4) | 3.07764064044151
--- 504,510 ----
ORDER BY distance, circle, point using <<;
twentyfour | circle | point | distance
------------+----------------+------------+-------------------
! | <(100,0),100> | (5.1,34.5) | 0.976531926977964
| <(1,2),3> | (-3,4) | 1.47213595499958
| <(0,0),3> | (-3,4) | 2
| <(100,0),100> | (-3,4) | 3.07764064044151
***************
*** 519,525 ****
| <(0,0),3> | (10,10) | 11.142135623731
| <(1,3),5> | (-5,-12) | 11.1554944214035
| <(1,2),3> | (-5,-12) | 12.2315462117278
! | <(1,3),5> | (5.1,34.5) | 26.7657047773223
| <(1,2),3> | (5.1,34.5) | 29.757594539282
| <(0,0),3> | (5.1,34.5) | 31.8749193547455
| <(100,200),10> | (5.1,34.5) | 180.778038568384
--- 519,525 ----
| <(0,0),3> | (10,10) | 11.142135623731
| <(1,3),5> | (-5,-12) | 11.1554944214035
| <(1,2),3> | (-5,-12) | 12.2315462117278
! | <(1,3),5> | (5.1,34.5) | 26.7657047773224
| <(1,2),3> | (5.1,34.5) | 29.757594539282
| <(0,0),3> | (5.1,34.5) | 31.8749193547455
| <(100,200),10> | (5.1,34.5) | 180.778038568384
======================================================================
*** ./expected/select_implicit.out Tue Sep 12 17:07:17 2000
--- ./results/select_implicit.out Thu Nov 22 22:16:50 2001
***************
*** 22,32 ****
c | count
----------+-------
AAAA | 2
BBBB | 2
CCCC | 2
XXXX | 1
- bbbb | 1
- cccc | 2
(6 rows)
-- w/o existing GROUP BY target using a relation name in GROUP BY clause
--- 22,32 ----
c | count
----------+-------
AAAA | 2
+ bbbb | 1
BBBB | 2
+ cccc | 2
CCCC | 2
XXXX | 1
(6 rows)
-- w/o existing GROUP BY target using a relation name in GROUP BY clause
***************
*** 34,44 ****
count
-------
2
2
2
- 1
- 1
2
(6 rows)
-- w/o existing GROUP BY target and w/o existing a different ORDER BY target
--- 34,44 ----
count
-------
2
+ 1
2
2
2
+ 1
(6 rows)
-- w/o existing GROUP BY target and w/o existing a different ORDER BY target
***************
*** 104,114 ****
c | count
----------+-------
AAAA | 2
BBBB | 2
CCCC | 2
XXXX | 1
- bbbb | 1
- cccc | 2
(6 rows)
-- group using reference number out of range
--- 104,114 ----
c | count
----------+-------
AAAA | 2
+ bbbb | 1
BBBB | 2
+ cccc | 2
CCCC | 2
XXXX | 1
(6 rows)
-- group using reference number out of range
======================================================================
*** ./expected/select_having.out Thu Jan 6 01:40:54 2000
--- ./results/select_having.out Thu Nov 22 22:16:48 2001
***************
*** 34,41 ****
GROUP BY c HAVING count(*) > 2 OR min(a) = max(a);
c | max
----------+-----
- XXXX | 0
bbbb | 5
(2 rows)
DROP TABLE test_having;
--- 34,41 ----
GROUP BY c HAVING count(*) > 2 OR min(a) = max(a);
c | max
----------+-----
bbbb | 5
+ XXXX | 0
(2 rows)
DROP TABLE test_having;
======================================================================
*** ./expected/select_views.out Sat Oct 13 13:41:11 2001
--- ./results/select_views.out Thu Nov 22 22:17:04 2001
***************
*** 467,472 ****
--- 467,486 ----
I- 580 | 21
I- 580 | 22
I- 580 | 22
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 4
+ I- 580/I-680 Ramp | 4
+ I- 580/I-680 Ramp | 4
+ I- 580/I-680 Ramp | 4
+ I- 580/I-680 Ramp | 5
+ I- 580/I-680 Ramp | 6
+ I- 580/I-680 Ramp | 6
+ I- 580/I-680 Ramp | 6
I- 580 Ramp | 2
I- 580 Ramp | 2
I- 580 Ramp | 2
***************
*** 717,736 ****
I- 580 Ramp | 8
I- 580 Ramp | 8
I- 580 Ramp | 8
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 4
- I- 580/I-680 Ramp | 4
- I- 580/I-680 Ramp | 4
- I- 580/I-680 Ramp | 4
- I- 580/I-680 Ramp | 5
- I- 580/I-680 Ramp | 6
- I- 580/I-680 Ramp | 6
- I- 580/I-680 Ramp | 6
I- 680 | 2
I- 680 | 2
I- 680 | 2
--- 731,736 ----
======================================================================
Lamar Owen <lamar.owen@wgcr.org> writes:
Regression does the expected thing on RedHat 7.2 (locale settings prevent a
complete PASS -- the diffs are attached for those who are curious).
This seems rather broken, seeing as how "make check" takes pains to
create a C-locale temporary installation. How are you managing to
defeat that?
regards, tom lane
On Thu, 22 Nov 2001, Marc G. Fournier wrote:
I know what the problem is, and am currently working on getting it fixed,
right Vince? :)
Depends, you talking about the dns entry or the header line? I can
fix the dns entry, but not the header line.
On Thu, 22 Nov 2001, Tom Lane wrote:
"Marc G. Fournier" <scrappy@hub.org> writes:
if anyone would like to take a quick test
through and make sure the packaging isn't missing anything, the tar files
are avaialble at:
ftp://ftp.postgresql.org/pub/betaWhy do all the CVS $Header$ lines in this tarball look like
$Header: /projects/cvsroot/pgsql/GNUmakefile.in,v 1.23 2001/11/21 23:19:25 momjian Exp $
and not
$Header: /cvsroot/pgsql/GNUmakefile.in,v 1.23 2001/11/21 23:19:25 momjian Exp $
which is what I see in CVS checkout (as well as earlier beta tarballs)?
This makes it *real* painful to diff the tarball against my local
checkout, which is what I usually do to validate a tarball.I think it might be okay other than that, but it's hard to tell...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
On Thursday 22 November 2001 11:35 pm, Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
Regression does the expected thing on RedHat 7.2 (locale settings prevent
a complete PASS -- the diffs are attached for those who are curious).
This seems rather broken, seeing as how "make check" takes pains to
create a C-locale temporary installation. How are you managing to
defeat that?
By running the regression tests in a binary-only installation. I am of the
opinion that people might want to run regression, or have the regression
database, or see the regression queries as examples, on a non-development
machine -- one with no make. I myself, as part of the burn-in of new
database servers, run multiple regression tests on the soon-to-be production
server -- and I _never_ install compilers, make, or associated packages on
production servers.
So I prebuild the regression binaries, etc, and put them into a subpackage
called test -- then, the user just cd's to /usr/lib/pgsql/test/regress, makes
sure postmaster is running, su's to postgres, and runs ./pg_regress with the
right scheduling options. No source tree required. When done with the tests,
rpm -e postgresql-test frees up the 4MB of space taken.
ISTM that the regression tests should be locale-agnostic, or be able to force
a specific locale without requiring a make. It's not a big deal, as long as
you know what to expect, though. So, the regression results I just posted
should be considered normal for the binary-only regression test on a locale
of en_US. In fact, our regression testscould even be used to find broken
locales -- is there even a test for locale?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
This seems rather broken, seeing as how "make check" takes pains to
create a C-locale temporary installation. How are you managing to
defeat that?
By running the regression tests in a binary-only installation.
Remind me to pay no attention whatsoever to regression test failure
reports coming from people who use the RPM installation.
I regard this setup as worse than useless, because it is guaranteed
to cause regression failures that most people will not know how to
interpret. We will be getting lots of complaints, and I for one am
not going to waste my time scanning them closely to see if there is
anything real there.
ISTM that the regression tests should be locale-agnostic,
They are, when used as intended.
In reality, it's extremely questionable that the regression tests
will tell anything useful to a person who's installing prebuilt
platform-specific binaries. The builder of the binaries should have
run the regress tests. So I'm not sure what the point is --- but I am
sure that this setup will cause a lot more problems than it solves.
I recommend forgetting about postgresql-test.
regards, tom lane
On Friday 23 November 2001 11:08 am, Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
By running the regression tests in a binary-only installation.
Remind me to pay no attention whatsoever to regression test failure
reports coming from people who use the RPM installation.
I typically field those anyway.
I regard this setup as worse than useless, because it is guaranteed
to cause regression failures that most people will not know how to
interpret. We will be getting lots of complaints, and I for one am
not going to waste my time scanning them closely to see if there is
anything real there.
As this has been in the RPMset for, let's see, TWO YEARS now, I don't think
it's going to be that big of a problem. The locale deal has been there that
long -- and is something I can see a mile away -- which of course means that
I'll check those reports myself, and only will pass along the parts that are
real failures.
The discussion in a separate thread about being able to specify the collation
in queries sounds like it would solve a good deal of the problem, by
specifying the C collation in the regression queries. The other failures
involve a currency symbol, the presence of which still confuses me to a
certain extent.
They are, when used as intended.
And it is my contention that the 'make check' method of running regression
testing is broken in itself, by assuming a source tree, by assuming a
development platform, and by assuming that regression testing is a
developer-only activity. I disagree with all those assumptions -- our
documentation even has stated (and may still state) that the regression
database and the regression queries are a good source of examples -- both for
the queries, and for the datamodels.
But those three assumptions run deep -- particularly the first two, which
underlie the whole package's philosophy in more than one area.
I'm just providing what I believe is a useful feature that has been requested
by RPM, non-development-platform, users.
If I must, I can patch the expected outputs to match the default en_US locale
-- but I am very loathe to do that! After all, the en_US locale may not be
what the user is running.
In reality, it's extremely questionable that the regression tests
will tell anything useful to a person who's installing prebuilt
platform-specific binaries.
In reality, I think they are more useful than that to the enduser.
The builder of the binaries should have
run the regress tests.
I run them both in their 'intended' way as well as in the final prebuilt way
before releasing any RPMsets. There have been a couple of times that I
skipped that step, usually with bad results, but it is one of the things I
just do, now.
So I'm not sure what the point is --- but I am
sure that this setup will cause a lot more problems than it solves.
As the test subpackage has existed for two years, I would contend that the
package hasn't caused quite as many problems as you prophesy.
I recommend forgetting about postgresql-test.
If the consensus of the steering committee is that we shouldn't distribute
the postgresql-test subpackage prebuilt, from ftp.postgresql.org, I will
disable it in the build. The possibility to build it will still be
available: it would just not be built by default.
Again, I have fielded questions about RPM issues for over two years, now, and
I fully intend to continue doing so. The standard 'failures' will be fully
documented in the README.rpm-dist (the fact that there are known failures is
already documented) in the RPMset, which is where someone who wants to run
the tests is going to have to go for information on running the tests
themselves. So, Tom, while I understand your concerns, I just want to make
sure it is realized that this is not a new thing, and that I volunteer to
field those results.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
On Saturday 24 November 2001 03:08, Tom Lane wrote:
In reality, it's extremely questionable that the regression tests
will tell anything useful to a person who's installing prebuilt
platform-specific binaries. The builder of the binaries should have
run the regress tests. So I'm not sure what the point is --- but I am
sure that this setup will cause a lot more problems than it solves.
I recommend forgetting about postgresql-test.
Tom,
I have problems interpreting your statement.
I assumed that the purpose of a regression test is to verify that software
is doing what it is supposed to do on the system it as installed.
If I install a binary package, you say that I cannot rely on the
regression test? What does the builder of the package know about the
particularities of my system? How else could I verify the functionality of
the installed software?
Either the regression test is construed in a way that it works with any
installation, or users should be advised NOT to use binary packages at all
and only install in a way that they can verify the installation with the
regression test. How would you think any user would trust his/her
installation in a production environment otherwise?
Did I misunderstand your statement or is my trust in PostgreSQL binary
installations unjustified?
Horst
Horst Herb <hherb@malleenet.net.au> writes:
I assumed that the purpose of a regression test is to verify that software
is doing what it is supposed to do on the system it as installed.
So it is. What Lamar is proposing to provide as part of the RPMs is not
usable for that purpose, at least not easily. That's why I'm not happy.
A possible solution is to give pg_regress.sh a third behavior in which
it relies on an already-installed set of binaries and library files,
but still initdb's a temporary data area and starts a test postmaster
therein. That would allow controlling the locale issue in the tested
database. I'm not sure if this can be done easily enough to make it
a viable answer for 7.2, though. It's a tad late in the beta cycle
to be contemplating any major surgery on pg_regress.
Peter, any thoughts about how hard that might be?
regards, tom lane
On Friday 23 November 2001 06:55 pm, Tom Lane wrote:
Horst Herb <hherb@malleenet.net.au> writes:
I assumed that the purpose of a regression test is to verify that
software is doing what it is supposed to do on the system it as
installed.
So it is. What Lamar is proposing to provide as part of the RPMs is not
usable for that purpose, at least not easily. That's why I'm not happy.
It's not being proposed; it's existing behavior for two years. I'm not happy
with there being failures in the tests, either -- but I _have_ documented the
fact of failures.
A possible solution is to give pg_regress.sh a third behavior in which
it relies on an already-installed set of binaries and library files,
but still initdb's a temporary data area and starts a test postmaster
therein.
This would be helpful. While I understand the desire to be able to test a
set of binaries prior to installation (and support such a possibility), this
behavior should be the default, not the other way around. I shouldn't need
make to run regression.
And I'm willing to do the work. Unless Peter just wants to do it, I'll see
what I can get working for the 7.3 cycle.
I don't think it will be too hard, from a quick look at make check and
friends.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Tom Lane writes:
A possible solution is to give pg_regress.sh a third behavior in which
it relies on an already-installed set of binaries and library files,
but still initdb's a temporary data area and starts a test postmaster
therein.
This sounds like a good plan, but I refuse to even think about it further
so I don't get any ideas about trying it for 7.2. ;-)
--
Peter Eisentraut peter_e@gmx.net