Обсуждение: nasty problem with redhat 6.2 + pg 7.02
After more than two years of using postgresql with linux, this may turn to be my last frustration; not being able to find the problem, and with several thousands of customers that must pay on the FIRST day of each month, I find this NASTY; must I turn to oracle on solaris, I wonder.... Take a look at this: if you can't spot the problem, (I couldn't) at least you should be warned: this seems pretty serious. (using PGDATESTYLE=Postgres ) [postgres@ren postgres]$ createdb test1 CREATE DATABASE [postgres@ren postgres]$ echo "create table serv2 (fecha1 date,fecha2 date);" | psql test1 CREATE [postgres@ren postgres]$ echo "insert into serv2 values ('13-01-2000','01-10-2000');"| psql test1 INSERT 380928512 1 [postgres@ren postgres]$ echo "select * from serv2;" | psql test1 fecha1 | fecha2 ------------+------------ 13-01-2000 | 30-09-2000 (1 row) ?????? What's happening here ??? The 'lost day' ( 01-10-2000 => 30-09-2000 ) occurs with that date only, first october 2000... at least, I haven't found any other example The problem is rather random; (for some reason, it happens with less 'probability' :-((( if I create the table with only a field date2) I'm using RedHat 6.2 (having suffered recently the horrible 'sort -n' bug http://www.redhat.com/support/errata/RHBA-2000-040-01.html I'm having less and less confidence on this platform... but...) Actually, I could reproduce the problem in other rh 6.2 machine, but it does not appears with another machine running RH 6.1 BUT, the problem does not reveal on another machine, which has rh 6.2 (but pg was compiled over the previous rh 6.1 distro... could that make any difference)? Yes, I run the (complete) regression tests. All OK. More data follows below... Hernan Gonzalez Buenos Aires, Argentina hgonzal@sinectis.com.ar ########################################################################## [postgres@ren postgres]$ uname -a Linux ren.sinectis.com.ar 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown [postgres@ren postgres]$ cat /etc/redhat-release Red Hat Linux release 6.2 (Zoot) [postgres@ren postgres]$ echo "select version();" | psql test1 version --------------------------------------------------------------------- PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66 (1 row) [postgres@ren postgres]$ set (stripped) HOSTTYPE=i386 LANG=en_US LOGNAME=postgres OSTYPE=Linux PATH=/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/X11R6/bin:/home/postgres/bin:/sql/bin: PGDATA=/sql/data PGDATESTYLE=Postgres PGLIB=/sql/lib HOME=/home/postgres HOSTTYPE=i386 UID=500 USER=postgres USERNAME=
leonbloy@sinectis.com.ar wrote: > [postgres@ren postgres]$ echo "select * from serv2;" | psql test1 > fecha1 | fecha2 > ------------+------------ > 13-01-2000 | 30-09-2000 > (1 row) > ?????? What's happening here ??? I can't duplicate: test=# SET datestyle=postgres; SET VARIABLE test=# create table serv2 (fecha1 date, fecha2 date); CREATE test=# insert into serv2 values ('13-01-2000','01-10-2000'); INSERT 407754 1 test=# select * from serv2; fecha1 | fecha2 ------------+------------ 01-13-2000 | 01-10-2000 (1 row) test=# System is RedHat 6.2 with the PostgreSQL 7.0.2-2 RPMset loaded. Hmmm, but 13-01-2000 got flipped to 01-13-2000, and 01-10-2000 didn't flip... Now that is strange. Let's try something... test=# delete from serv2; DELETE 1 test=# insert into serv2 values ('10-01-2000','01-10-2000'); INSERT 407765 1 test=# select * from serv2; fecha1 | fecha2 ------------+------------ 10-01-2000 | 01-10-2000 (1 row) Nope, still right. Hmmm, if I insert '30-09-2000', I get: test=# select * from serv2; fecha1 | fecha2 ------------+------------ 01-13-2000 | 09-30-2000 (1 row) Now, this is with DATESTYLE set within the psql session using 'set datestyle' -- let's try the PGDATESTYLE variable... [lowen@utility www]$ export PGDATESTYLE=Postgres [lowen@utility www]$ psql -c "delete from serv2" test DELETE 1 [lowen@utility www]$ psql -c "insert into serv2 values ('13-01-2000','01-10-2000')" test INSERT 407808 1 [lowen@utility www]$ psql -c "select * from serv2" test fecha1 | fecha2 ------------+------------ 01-13-2000 | 01-10-2000 (1 row) [lowen@utility www]$ Still the same results as earlier. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Leon - I can't reproduce this with 7.0.2 on a Debian install, but it smacks of a timezone problem of some sort. Do you have any other environment variables set that might affect the interpretation of date/time info? Note that you've shown us the environment your running the _client_ in. What does the _server_ have set in it's environment? I'm not sure about RedHat: on Debian, it's set in /etc/postgresql/postgresql.env Note that I had to explicitly set "European" to get output that matched yours: just using "postgres" used US conventions. Here's my transcript: test=# create table serv2 (fecha1 date,fecha2 date); CREATE test=# insert into serv2 values ('13-01-2000','01-10-2000'); INSERT 712438 1 test=# set datestyle = European; SET VARIABLE test=# set datestyle = postgres; SET VARIABLE test=# show datestyle; NOTICE: DateStyle is Postgres with European conventions SHOW VARIABLE test=# insert into serv2 values ('13-01-2000','01-10-2000'); INSERT 712439 1 test=# select * from serv2; fecha1 | fecha2 ------------+------------ 13-01-2000 | 01-10-2000 13-01-2000 | 01-10-2000 (2 rows) test=# select version(); version --------------------------------------------------------------- PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.95.2 (1 row) test=# Ross On Tue, Sep 19, 2000 at 11:37:52AM -0300, leonbloy@sinectis.com.ar wrote: > After more than two years of using postgresql with linux, this > may turn to be my last frustration; not being able to find the > problem, and with several thousands of customers that must pay > on the FIRST day of each month, I find this NASTY; must I > turn to oracle on solaris, I wonder.... > > Take a look at this: if you can't spot the problem, > (I couldn't) at least you should be warned: this > seems pretty serious. > > (using PGDATESTYLE=Postgres ) > > > [postgres@ren postgres]$ createdb test1 > CREATE DATABASE > [postgres@ren postgres]$ echo "create table serv2 (fecha1 date,fecha2 date);" | > psql test1 > CREATE > [postgres@ren postgres]$ echo "insert into serv2 values > ('13-01-2000','01-10-2000');"| psql test1 > INSERT 380928512 1 > [postgres@ren postgres]$ echo "select * from serv2;" | psql test1 > fecha1 | fecha2 > ------------+------------ > 13-01-2000 | 30-09-2000 > (1 row) > > > ?????? What's happening here ??? > -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
On Tue, Sep 19, 2000 at 12:36:22PM -0400, Lamar Owen wrote: > > I can't duplicate: > test=# SET datestyle=postgres; > SET VARIABLE > test=# create table serv2 (fecha1 date, fecha2 date); > CREATE > test=# insert into serv2 values ('13-01-2000','01-10-2000'); > INSERT 407754 1 > test=# select * from serv2; > fecha1 | fecha2 > ------------+------------ > 01-13-2000 | 01-10-2000 > (1 row) > > test=# > System is RedHat 6.2 with the PostgreSQL 7.0.2-2 RPMset loaded. Hmmm, > but 13-01-2000 got flipped to 01-13-2000, and 01-10-2000 didn't flip... > Now that is strange. Right: Lamar, you're using US conventions. Leon appears to be using European. One of the postgresql 'features' is that it will try hard to parse dates, even using the other convention if necessary. There is no 13th month, so the first one got taken directly. The 10th of January, on the other hand... This looks suspiciously like a timezone/daylight savings time issue, to me. Somewhere, the date is getting represented as a full date/time, then an hour is getting subtracted, then truncated to a date again. Leon, try something like: INSERT INTO serv2 VALUES ('13-01-2000'::date,'01-10-2000'::date); That _might_ force the correct conversion, but I cant' test it, since I don't see your problem here. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
> On Tue, Sep 19, 2000 at 12:36:22PM -0400, Lamar Owen wrote: > > > > I can't duplicate: > > test=# SET datestyle=postgres; > > SET VARIABLE > > test=# create table serv2 (fecha1 date, fecha2 date); > > CREATE > > test=# insert into serv2 values ('13-01-2000','01-10-2000'); > > INSERT 407754 1 > > test=# select * from serv2; > > fecha1 | fecha2 > > ------------+------------ > > 01-13-2000 | 01-10-2000 > > (1 row) > > > > test=# > > System is RedHat 6.2 with the PostgreSQL 7.0.2-2 RPMset loaded. Hmmm, Right. I tried on a machine with the RPM set, and all went OK. My problem appears with a compiled 7.02 distro (no special switches, no locales) > > This looks suspiciously like a timezone/daylight savings time issue, to > me. Somewhere, the date is getting represented as a full date/time, then > an hour is getting subtracted, then truncated to a date again. > > INSERT INTO serv2 VALUES ('13-01-2000'::date,'01-10-2000'::date); > > That _might_ force the correct conversion, but I cant' test it, since > I don't see your problem here. > No luck: test1=# create table servx (fechax date); CREATE test1=# insert into servx values ('01-10-2000'); INSERT 81748516 1 test1=# select * from servx; fechax ------------ 30-09-2000 (1 row) test1=# insert into servx values ('01-10-2000'::date); INSERT 81748517 1 test1=# select * from servx; fechax ------------ 30-09-2000 30-09-2000 (2 rows) And (to make things worse) the result is rather random: On the same machine, I start another db ... [postgres@bert postgres]$ createdb test2 CREATE DATABASE [postgres@bert postgres]$ psql test2 Welcome to psql, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit test2=# create table servx (fechax date); CREATE test2=# insert into servx values ('01-10-2000'); INSERT 81748585 1 test2=# select * from servx; fechax ------------ 01-10-2000 (1 row) test2=# insert into servx values ('01-10-2000'::date); INSERT 81748586 1 test2=# select * from servx; fechax ------------ 01-10-2000 01-10-2000 (2 rows) test2=# create table servxx (fechax date,fechaxx date); CREATE test2=# insert into servxx values ('01-10-2000','01-10-2000'); INSERT 81748597 1 test2=# select * from servxx; fechax | fechaxx ------------+------------ 01-10-2000 | 01-10-2000 (1 row) test2=# insert into servxx values ('13-10-2000','01-10-2000'); INSERT 81748598 1 test2=# select * from servxx; fechax | fechaxx ------------+------------ 01-10-2000 | 01-10-2000 13-10-2000 | 30-09-2000 Aaggghhh!!!! Thanks, anyway Hernan Gonzalez Argentina
On Tue, 19 Sep 2000, Lamar Owen wrote: > I can't duplicate: > test=# SET datestyle=postgres; Me neither and I didn't set the datestyle - based on your RPM set. Rod -- Roderick A. Anderson raanders@altoplanos.net Altoplanos Information Systems, Inc. Voice: 208.765.6149 212 S. 11th Street, Suite 5 FAX: 208.664.5299 Coeur d'Alene, ID 83814
> > On Tue, Sep 19, 2000 at 12:36:22PM -0400, Lamar Owen wrote: > > This looks suspiciously like a timezone/daylight savings time issue, to > > me. Somewhere, the date is getting represented as a full date/time, then > > an hour is getting subtracted, then truncated to a date again. > > Yes, it's certainly that kind of issue. I tried changing my timezone (I was using America/Buenos Aires) and the problem seems to disappear. But... why ? how ? what?? Who is to blame ? RedHat, linux or postgres ? In any case, this should never afect a 'date' type field! Cheers Hernan Gonzalez Buenos Aires, Argentina
Sorry for the verbosity, but I forgot to answer this one: > Leon - > I can't reproduce this with 7.0.2 on a Debian install, but it smacks > of a timezone problem of some sort. Do you have any other environment > variables set that might affect the interpretation of date/time info? > Timezone is set to America/Buenos Aires Changing this seems to elliminate the bug. > Note that you've shown us the environment your running the _client_ > in. What does the _server_ have set in it's environment? I'm not sure > about RedHat: on Debian, it's set in /etc/postgresql/postgresql.env > The example I posted was run on the server. I.e., the settings are those of the server AND the client Thanx Hernan Gonzalez Argentina
Lamar Owen <lamar.owen@wgcr.org> writes: > leonbloy@sinectis.com.ar wrote: >> [postgres@ren postgres]$ echo "select * from serv2;" | psql test1 >> fecha1 | fecha2 >> ------------+------------ >> 13-01-2000 | 30-09-2000 >> (1 row) >> ?????? What's happening here ??? > I can't duplicate: You won't duplicate it on that date, unless you are in the same timezone he is --- I believe it's a daylight-savings-transition issue. Attached are some comments I sent to Hernan privately. regards, tom lane To: Hernan Gonzalez <hgonzal@sinectis.com.ar> Subject: Re: problem with postgres Date: Fri, 15 Sep 2000 19:02:06 -0400 From: Tom Lane <tgl@sss.pgh.pa.us> Hernan <hgonzal@sinectis.com.ar> writes: > The 'lost day' ( 01-10-2000 => 30-09-2000 ) occurs with > that date only, first october 2000... at least, I haven't found any > other example Would that happen to be a daylight-savings transition boundary in your timezone? There have been some discussions recently about whether conversions between timestamp and date behave reasonably at a DST boundary. It's possible that you're getting bit by a bug of that sort, though I wouldn't have thought it'd happen without a datatype conversion. In my zone (EST5EDT) Postgres 7.0.2 has this problem on the spring transition date: play=> select '2000-04-02'::date; ?column? ------------ 2000-04-02 (1 row) play=> select '2000-04-02'::date::timestamp; ?column? ------------------------ 2000-04-01 23:00:00-05 <<=== oops, off by an hour (1 row) play=> select '2000-04-02'::date::timestamp::date; ?column? ------------ 2000-04-01 (1 row) This is fixed in current sources for 7.1. I don't see how this would apply to just inserting data into a date column, but maybe there's some related problem that's biting you. regards, tom lane
Well, I've tracked down the problem to its mininal form, I think: Here it goes: [postgres@bert postgres]$ createdb test5 CREATE DATABASE [postgres@bert postgres]$ psql test5 Welcome to psql, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit test5=# select '01-10-2000'::date; ?column? ------------ 01-10-2000 (1 row) test5=# select '13-10-2000'::date; ?column? ------------ 13-10-2000 (1 row) test5=# select '01-10-2000'::date; ?column? ------------ 30-09-2000 (1 row) Strange, isnt' it ? Also: [postgres@bert postgres]$ createdb test6 CREATE DATABASE [postgres@bert postgres]$ psql test6 Welcome to psql, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit test6=# select '01-10-2000'::date::timestamp; ?column? ------------------------------ Sat 30 Sep 23:00:00 2000 ART (1 row) test6=# select '13-10-2000'::date::timestamp; ?column? ------------------------------- Fri 13 Oct 00:00:00 2000 ARST (1 row) test6=# select '01-10-2000'::date::timestamp; ?column? ------------------------------ Sat 30 Sep 00:00:00 2000 ART (1 row) The first result (30 sept 23:00:00) is obviously due to a timezone-daylight saving issue. But why postgresql throws a different result afterwards, is more than I can explain. Cheers Hernan
leonbloy@sinectis.com.ar writes: > Timezone is set to America/Buenos Aires > Changing this seems to elliminate the bug. What did you change it *to*, exactly? And what dates did you test after changing? I would expect the bug to follow the DST transition date, which varies in different timezones. Also, since it's the spring-forward transition where you can see the problem, for zones north of the equator you'd be needing to check the March-ish transition date not the October-ish one. In my experience, timekeeping routines often have to distinguish between northern and southern timezones in order to do DST properly. It could be that you're looking at some bug in RedHat 6.2's libc that only manifests for southern timezones. If so that might explain why the rest of us haven't seen it. regards, tom lane
for what it's worth, when i run these two tests, i get the correct results i'm using RedHat 6.2 also. here are more details: [ebridges@sleeepy]$ uname -a Linux sleeepy 2.2.16 #2 SMP Mon Jul 31 14:51:33 EDT 2000 i686 unknown [ebridges@sleeepy]$ psql -V psql (PostgreSQL) 7.0.2 Portions Copyright (c) 1996-2000, PostgreSQL, Inc . . . i compiled/installed postgres from a tarball. are you using the RPM? or did you compile from scratch? if the former, perhaps it's a bug in the redhat binary rpm. HTH --e-- On Tue, 19 Sep 2000 15:44:15 -0300, leonbloy@sinectis.com.ar wrote: > Well, I've tracked down the problem to its > mininal form, I think: > > Here it goes: > > [postgres@bert postgres]$ createdb test5 > CREATE DATABASE > [postgres@bert postgres]$ psql test5 > Welcome to psql, the PostgreSQL interactive terminal. > > Type: \copyright for distribution terms > \h for help with SQL commands > \? for help on internal slash commands > \g or terminate with semicolon to execute query > \q to quit > > test5=# select '01-10-2000'::date; > ?column? > ------------ > 01-10-2000 > (1 row) > > test5=# select '13-10-2000'::date; > ?column? > ------------ > 13-10-2000 > (1 row) > > test5=# select '01-10-2000'::date; > ?column? > ------------ > 30-09-2000 > (1 row) > > Strange, isnt' it ? > Also: > > [postgres@bert postgres]$ createdb test6 > CREATE DATABASE > [postgres@bert postgres]$ psql test6 > Welcome to psql, the PostgreSQL interactive terminal. > > Type: \copyright for distribution terms > \h for help with SQL commands > \? for help on internal slash commands > \g or terminate with semicolon to execute query > \q to quit > > test6=# select '01-10-2000'::date::timestamp; > ?column? > ------------------------------ > Sat 30 Sep 23:00:00 2000 ART > (1 row) > > test6=# select '13-10-2000'::date::timestamp; > ?column? > ------------------------------- > Fri 13 Oct 00:00:00 2000 ARST > (1 row) > > test6=# select '01-10-2000'::date::timestamp; > ?column? > ------------------------------ > Sat 30 Sep 00:00:00 2000 ART > (1 row) > > > The first result (30 sept 23:00:00) is obviously due to > a timezone-daylight saving issue. > But why postgresql throws a different result afterwards, > is more than I can explain. > > Cheers > > Hernan > > >
leonbloy@sinectis.com.ar writes: > test6=# select '01-10-2000'::date::timestamp; > ?column? > ------------------------------ > Sat 30 Sep 23:00:00 2000 ART > (1 row) > test6=# select '13-10-2000'::date::timestamp; > ?column? > ------------------------------- > Fri 13 Oct 00:00:00 2000 ARST > (1 row) > test6=# select '01-10-2000'::date::timestamp; > ?column? > ------------------------------ > Sat 30 Sep 00:00:00 2000 ART > (1 row) > The first result (30 sept 23:00:00) is obviously due to > a timezone-daylight saving issue. > But why postgresql throws a different result afterwards, > is more than I can explain. I'll bet there is some bit of internal state somewhere that affects the results. It could be inside libc, or it could be in Postgres. I seem to recall that we have some timezone info that gets computed on the first call of a timezone-related operation and then saved thereafter; maybe that's related somehow. libc probably also saves timezone information across calls. If you alter the order of the inquiries, how do the results change? Thomas Lockhart is our lead guy on date/time operations, and it's clearly time to get him involved. Thomas, have you noticed this thread? Any luck reproducing the problem? regards, tom lane
Tom Lane wrote: >> Timezone is set to America/Buenos Aires >> Changing this seems to elliminate the bug. > What did you change it *to*, exactly? And what dates did you test > after changing? I changed to "Etc/GMT+4" and tested the same just the same dates >>>>>>>>>>>>>>>>>>>>>>>>> Edward Q. Bridges wrote: >i compiled/installed postgres from a tarball. are you > using the RPM? or did you compile from scratch? I compiled the sources too. >>>>>>>>>>>>> Tom Lane wrote: >I'll bet there is some bit of internal state somewhere that affects >the results. It could be inside libc, or it could be in Postgres. postgres, I would tend to think... For one thing I've just found out: the 'histeresis' effect occurs only WITHIN A CONNECTION: If I run this script: #################################### # !/usr/bin/perl use DBI; $host = 'localhost'; $db = 'test5'; my $db1; $db1 = DBI->connect("dbi:Pg:dbname=$db; host=$host;port=5432",'postgres',''); doit('01-10-2000'); doit('13-10-2000'); doit('01-10-2000'); sub doit { my($fecha)=@_; my $sth = $db1->prepare("SELECT '$fecha'::date::timestamp"); my $rv = $sth->execute; my ($x)=$sth->fetchrow_array; print "$fecha => $x\n"; } #####################################3 I get: [postgres@bert postgres]$ perl pru.pl 01-10-2000 => Sat 30 Sep 23:00:00 2000 ART 13-10-2000 => Fri 13 Oct 00:00:00 2000 ARST 01-10-2000 => Sat 30 Sep 00:00:00 2000 ART [postgres@bert postgres]$ If I intermix a disconnect/connect between the calls to doit() I get: [postgres@bert postgres]$ perl pru.pl 01-10-2000 => Sat 30 Sep 23:00:00 2000 ART 13-10-2000 => Fri 13 Oct 00:00:00 2000 ARST 01-10-2000 => Sat 30 Sep 23:00:00 2000 ART [postgres@bert postgres]$ By the way, on another redhat 6.1 machine (fortunately, my postgres producion server) with the same timezone, the results are just right: [postgres@crisol postgres]$ perl pru.pl 01-10-2000 => Sun 01 Oct 00:00:00 2000 ART 13-10-2000 => Fri 13 Oct 00:00:00 2000 ART 01-10-2000 => Sun 01 Oct 00:00:00 2000 ART This is getting a little boring for the rest of the list, i suppose... should I send this to the hackers list? or mail it privately ? Regards. Hernan Gonzalez Argentina
leonbloy@sinectis.com.ar writes: > Tom Lane wrote: >> I'll bet there is some bit of internal state somewhere that affects >> the results. It could be inside libc, or it could be in Postgres. > postgres, I would tend to think... > For one thing I've just found out: the 'histeresis' effect occurs > only WITHIN A CONNECTION: Doesn't prove a thing. The libc state I'm thinking of would be recomputed on first use within a given process, ie, per backend. So we still have no idea if the problem is libc's or Postgres'. Given that the problem seems to be specific to your timezone, and Postgres itself knows very little about timezones, a libc bug is well within the realm of possibility. Is anyone else able to reproduce this misbehavior at a DST boundary? regards, tom lane
> > The first result (30 sept 23:00:00) is obviously due to > > a timezone-daylight saving issue. Fixed in current sources by using mktime() rather than by rotating the date to 12 noon to try to get the correct time zone (didn't work around daylight savings time). > Thomas Lockhart is our lead guy on date/time operations, and it's > clearly time to get him involved. Thomas, have you noticed this > thread? Any luck reproducing the problem? Hmm, didn't see the thread (I unsubscribed from -general due to mailing list overload). And I don't yet see the problem on my machine: setenv PGTZ America/Buenos_Aires lockhart=# set datestyle='postgres,european'; lockhart=# select '01-10-2000'::date::timestamp; Sun 01 Oct 00:00:00 2000 ART lockhart=# select '13-10-2000'::date::timestamp; Fri 13 Oct 00:00:00 2000 ART lockhart=# select '01-10-2000'::date::timestamp; Sun 01 Oct 00:00:00 2000 ART lockhart=# select version(); PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.95.3 This is on a Mandrake 7.1 box with RPMs built from Lamar's source RPMs. Can someone else reproduce the problem on a RedHat 6.2 box? - Thomas