Thread: 7.3.1: test select_having ... FAILED
Looks like this select_having regression test was fixed by tgl on the HEAD Nov 21 2002 to use ORDER BY queries to avoid random outputs, but I was surprised it did not make it into 7.3.1. I haven't been keeping up with discussion of merge plans or std practice, so I wondered if the merge might have fallen thru a crack? Ed
"Ed L." <pggeneral@bluepolka.net> writes:
> Looks like this select_having regression test was fixed by tgl on the
> HEAD Nov 21 2002 to use ORDER BY queries to avoid random outputs, but
> I was surprised it did not make it into 7.3.1.
The change I made was unrelated to 7.3.*. I suspect you are looking at
a locale issue --- was this a "make check" or "make installcheck", and
if the latter, what locale is the server using?
regards, tom lane
On Saturday 28 December 2002 14:26, Tom Lane wrote:
> "Ed L." <pggeneral@bluepolka.net> writes:
> > Looks like this select_having regression test was fixed by tgl on
> > the HEAD Nov 21 2002 to use ORDER BY queries to avoid random
> > outputs, but I was surprised it did not make it into 7.3.1.
>
> The change I made was unrelated to 7.3.*. I suspect you are
> looking at a locale issue --- was this a "make check" or "make
> installcheck", and if the latter, what locale is the server using?
This was encountered with the following:
cd .../src/test/regress
gmake clean
gmake all runtest
As for locales, don't know much about those. This is a fresh redhat
8.0 install with plain vanilla defaults for US english, etc. env |
grep LC shows nothing. LANG=en_US.UTF-8, the default setting. Still,
my relatively uninformed look into the regression test files shows me
missing ORDER BY clauses, as you can see below, which would seem to
explain it.
Ed
# pwd
.../postgresql-7.3.1/src/test/regress
# diff expected/select_having.out results/select_having.out
29d28
< 3 | BBBB
30a30
> 3 | BBBB
46d45
< XXXX | 0
47a47
> XXXX | 0
# cat -n expected/select_having.out
...
24 -- HAVING is equivalent to WHERE in this case
25 SELECT b, c FROM test_having
26 GROUP BY b, c HAVING b = 3;
27 b | c
28 ---+----------
29 3 | BBBB
30 3 | bbbb
31 (2 rows)
...
# cat -n results/select_having.out
...
24 -- HAVING is equivalent to WHERE in this case
25 SELECT b, c FROM test_having
26 GROUP BY b, c HAVING b = 3;
27 b | c
28 ---+----------
29 3 | bbbb
30 3 | BBBB
31 (2 rows)
...
The select_having regression test fails pg 7.3.2 just as it did in
7.3.1. Upon inspection, the 7.3.2 code (select_having.sql) does not
include the "ORDER BY" clauses needed to pass the test. The CVS log
indicates you fixed the problem in rev 1.8 (the head) of
select_having.sql on 2003-11-21, but CVS shows the following tags:
REL7_3_2: 1.7
REL7_2_4: 1.4
REL7_3_STABLE: 1.7.0.2
This is not a functional problem, just a red herring. I don't
understand why this committed fix is not making its way into the
latest releases?
Thanks,
Ed
On Saturday December 28 2002 10:13, Ed L. wrote:
> On Saturday 28 December 2002 14:26, Tom Lane wrote:
> > "Ed L." <pggeneral@bluepolka.net> writes:
> > > Looks like this select_having regression test was fixed by tgl
> > > on the HEAD Nov 21 2002 to use ORDER BY queries to avoid random
> > > outputs, but I was surprised it did not make it into 7.3.1.
> >
> > The change I made was unrelated to 7.3.*. I suspect you are
> > looking at a locale issue --- was this a "make check" or "make
> > installcheck", and if the latter, what locale is the server
> > using?
>
> This was encountered with the following:
>
> cd .../src/test/regress
> gmake clean
> gmake all runtest
>
> As for locales, don't know much about those. This is a fresh
> redhat 8.0 install with plain vanilla defaults for US english, etc.
> env | grep LC shows nothing. LANG=en_US.UTF-8, the default
> setting. Still, my relatively uninformed look into the regression
> test files shows me missing ORDER BY clauses, as you can see below,
> which would seem to explain it.
>
> Ed
>
> # pwd
> .../postgresql-7.3.1/src/test/regress
> # diff expected/select_having.out results/select_having.out
> 29d28
> < 3 | BBBB
> 30a30
>
> > 3 | BBBB
>
> 46d45
> < XXXX | 0
> 47a47
>
> > XXXX | 0
>
> # cat -n expected/select_having.out
> ...
> 24 -- HAVING is equivalent to WHERE in this case
> 25 SELECT b, c FROM test_having
> 26 GROUP BY b, c HAVING b = 3;
> 27 b | c
> 28 ---+----------
> 29 3 | BBBB
> 30 3 | bbbb
> 31 (2 rows)
> ...
> # cat -n results/select_having.out
> ...
> 24 -- HAVING is equivalent to WHERE in this case
> 25 SELECT b, c FROM test_having
> 26 GROUP BY b, c HAVING b = 3;
> 27 b | c
> 28 ---+----------
> 29 3 | bbbb
> 30 3 | BBBB
> 31 (2 rows)
> ...
"Ed L." <pggeneral@bluepolka.net> writes:
> The select_having regression test fails pg 7.3.2 just as it did in
> 7.3.1. Upon inspection, the 7.3.2 code (select_having.sql) does not
> include the "ORDER BY" clauses needed to pass the test.
You're missing the point: ORDER BY does not fix this, because the
problem is that the ordering is different in the locale you're using.
regards, tom lane
On Monday February 10 2003 1:50, Tom Lane wrote: > "Ed L." <pggeneral@bluepolka.net> writes: > > The select_having regression test fails pg 7.3.2 just as it did > > in 7.3.1. Upon inspection, the 7.3.2 code (select_having.sql) > > does not include the "ORDER BY" clauses needed to pass the test. > > You're missing the point: ORDER BY does not fix this, because the > problem is that the ordering is different in the locale you're > using. Then my locale would need to match the locale in which the expected test result was created in order to give the test result validity? What was the locale in which the expected results were created? What was the point of your addition of ORDER BY clauses in rev 1.8? Thanks, Ed
"Ed L." <pggeneral@bluepolka.net> writes:
> Then my locale would need to match the locale in which the expected
> test result was created in order to give the test result validity?
Yup.
> What was the locale in which the expected results were created?
C. (If you do "make check" then the regression script will set up
a temp installation with the expected locale.)
> What was the point of your addition of ORDER BY clauses in rev 1.8?
At the time, the newly-added hash-aggregation code would be used for
these queries, causing them to produce results in an order that had
nothing to do with any locale's notion of sortedness. I could actually
revert the 1.8 changes, I think, because it was an error for hashing
to be used on char(N) data, and as of now the planner doesn't do it
anymore.
regards, tom lane
On Monday February 10 2003 4:28, Tom Lane wrote: > C. (If you do "make check" then the regression script will set up > a temp installation with the expected locale.) OK, that worked here. I had been running 'gmake all runtest' for quite a while, but guess it is time for a script tweak. Thanks, Ed