strange regression failure
Has anyone got any idea on why I see things like this from time to time?
It seems to be intermittent, which is odd.
You can see it on occasional ContribCheck failures on buildfarm.
cheers
andrew
Attachments:
badoutdifftext/plain; name=badoutdiffDownload
================= pgsql.2428/contrib/tsearch2/regression.diffs ===================
*** ./expected/tsearch2.out Wed Dec 15 10:34:05 2004
--- ./results/tsearch2.out Wed Dec 15 10:47:34 2004
***************
*** 2090,2096 ****
Upon a woman s face. E. J. Pratt (1882 1964)
', to_tsquery('sea&thousand&years'));
headline
! -----------------------------------------------------------------------------------------------------------------------
<b>sea</b> a <b>thousand</b> <b>years</b>,
A <b>thousand</b> <b>years</b> to trace
The granite features of this cliff
--- 2090,2096 ----
Upon a woman s face. E. J. Pratt (1882 1964)
', to_tsquery('sea&thousand&years'));
headline
! --------------------------------------------
<b>sea</b> a <b>thousand</b> <b>years</b>,
A <b>thousand</b> <b>years</b> to trace
The granite features of this cliff
***************
*** 2107,2113 ****
Upon a woman s face. E. J. Pratt (1882 1964)
', to_tsquery('granite&sea'));
headline
! --------------------------------------------------------------------------------------------------
<b>sea</b> a thousand years,
A thousand years to trace
The <b>granite</b> features of this cliff
--- 2107,2113 ----
Upon a woman s face. E. J. Pratt (1882 1964)
', to_tsquery('granite&sea'));
headline
! ------------------------------
<b>sea</b> a thousand years,
A thousand years to trace
The <b>granite</b> features of this cliff
***************
*** 2124,2130 ****
Upon a woman s face. E. J. Pratt (1882 1964)
', to_tsquery('sea'));
headline
! -------------------------------------------------------------------------------------------
<b>sea</b> a thousand years,
A thousand years to trace
The granite features of this cliff
--- 2124,2130 ----
Upon a woman s face. E. J. Pratt (1882 1964)
', to_tsquery('sea'));
headline
! ------------------------------
<b>sea</b> a thousand years,
A thousand years to trace
The granite features of this cliff
***************
*** 2144,2150 ****
</html>',
to_tsquery('sea&foo'), 'HighlightAll=true');
headline
! -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<html>
<!-- some comment -->
--- 2144,2150 ----
</html>',
to_tsquery('sea&foo'), 'HighlightAll=true');
headline
! ----------
<html>
<!-- some comment -->
Andrew Dunstan <andrew@dunslane.net> writes:
Has anyone got any idea on why I see things like this from time to time?
It seems to be intermittent, which is odd.
I have a suspicion that the unexpected result occurs when the client
encoding is UTF8, because psql/mbprint.c's ucs_wcwidth() function goes
belly up on control characters (which it probably shouldn't; for that
matter, that entire file should be removed and replaced with our real
multibyte support...).
What's not apparent is why the failure wouldn't be consistent. You'd
think the buildfarm would always run the test with the same encoding
selection. Any idea how that might not happen?
regards, tom lane
Andrew Dunstan <andrew@dunslane.net> writes:
Has anyone got any idea on why I see things like this from time to time?
It seems to be intermittent, which is odd.
I have a suspicion that the unexpected result occurs when the client
encoding is UTF8,
In fact, I was able to duplicate the failure after "initdb -E unicode".
So it would seem that the question is why the buildfarm environment
isn't controlling the locale setting. You must sometimes be running
with a LANG or LC_ALL setting that selects a unicode-based locale.
because psql/mbprint.c's ucs_wcwidth() function goes
belly up on control characters (which it probably shouldn't; for that
matter, that entire file should be removed and replaced with our real
multibyte support...).
I'm more than half tempted to do this, but I suppose it's too late in
the release cycle ...
regards, tom lane
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Has anyone got any idea on why I see things like this from time to time?
It seems to be intermittent, which is odd.I have a suspicion that the unexpected result occurs when the client
encoding is UTF8, because psql/mbprint.c's ucs_wcwidth() function goes
belly up on control characters (which it probably shouldn't; for that
matter, that entire file should be removed and replaced with our real
multibyte support...).
Well, based on your recent classification of the TODO list as items that
are either very hard or that noone wants to do, perhaps it deserves an
entry ;-)
What's not apparent is why the failure wouldn't be consistent. You'd
think the buildfarm would always run the test with the same encoding
selection. Any idea how that might not happen?
No. buildfarm itself does nothing to set the encoding for either the
server or the client. I guess we should make sure to use C/SQL_ASCII as
the locale/encoding settings when we initdb after the temp install.
Right now any environment settings inherited by the script are passed
through. I guess for the sake of completeness I should also set
PGCLIENTENCODING.
But I too find the inconsistency a mystery. I have seen ity once on my
test machine (dog) here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dog&dt=2004-11-30%2019:22:01
The time suggests that unlike my usual tests which are run from cron at
6 minutes past the hour this one was probably run by hand from the
command line for some reason, where I have LANG set to "en_US.UTF-8" -
don't know if that makes a difference.
cheers
andrew
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Has anyone got any idea on why I see things like this from time to time?
It seems to be intermittent, which is odd.I have a suspicion that the unexpected result occurs when the client
encoding is UTF8,In fact, I was able to duplicate the failure after "initdb -E unicode".
So it would seem that the question is why the buildfarm environment
isn't controlling the locale setting. You must sometimes be running
with a LANG or LC_ALL setting that selects a unicode-based locale.
Our emails just crossed. You got it. I will have buildfarm force SQL_ASCII.
cheers
andrew
On Wed, Dec 15, 2004 at 05:20:28PM -0500, Andrew Dunstan wrote:
Our emails just crossed. You got it. I will have buildfarm force SQL_ASCII.
But then you will lose reports using other encodings ...
--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Cuando ma�ana llegue pelearemos segun lo que ma�ana exija" (Mowgli)
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
On Wed, Dec 15, 2004 at 05:20:28PM -0500, Andrew Dunstan wrote:
Our emails just crossed. You got it. I will have buildfarm force SQL_ASCII.
But then you will lose reports using other encodings ...
"make check" forces C locale anyway. It's only the installed server
used by the contrib tests that could be affected.
regards, tom lane
Tom Lane wrote:
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
On Wed, Dec 15, 2004 at 05:20:28PM -0500, Andrew Dunstan wrote:
Our emails just crossed. You got it. I will have buildfarm force SQL_ASCII.
But then you will lose reports using other encodings ...
"make check" forces C locale anyway. It's only the installed server
used by the contrib tests that could be affected.
Yes, quite so. The tiny change has gone into buildfarm's CVS.
Alvaro does have a point, though - there are many things we don't test
that possibly we should - including locale and encoding differences. A
better testing regime for the PLs is another thing that springs to mind.
Also, currently buildfarm just runs postgres' own test suites. I'm not
averse to supporting a more extensive test suite just for farm members,
if people think that's a good idea.
just some blue sky ideas
cheers
andrew
On Wed, 2004-12-15 at 21:33 -0500, Andrew Dunstan wrote:
Also, currently buildfarm just runs postgres' own test suites. I'm not
averse to supporting a more extensive test suite just for farm members,
if people think that's a good idea.
I think you'd get more mileage out of expanding the existing PG test
suites, or adding new ones -- and then running those additional tests in
the build farm. But I agree that there's a lot we're not testing that we
should.
-Neil