Обсуждение: 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
================= 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
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
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)
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