Thread: 7.4.2 Regression tests: test stats loops indefinately...
Hi,
(I have't gotten any response to this on pgsql-admin@, so I'm resending
it to pgsql-general@... sorry for the annoyance.)
I'm installing Postgresql 7.4.2 on an OpenBSD/sparc64 computer running
OpenBSD 3.5. Postgresql builds fine, and all of the regression tests
pass (when I use MAX_CONNECTIONS=10), except for the stats test.
the end of results/stats.out is:
-- let stats collector catch up
SELECT sleep('0:0:2'::interval);
everything up till and including that matches expected/stats.out... but
the test simply stalls there. Unless I manuall kill the process, the
postmaster simply keeps soaking up CPU time indefinately. A look through
the three log files didn't turn up anything that looked like it was
related to the the stat's system. :-\
Any ideas?
-Vik
--
vikram vinayak kulkarni Every civilization must contend with an
vkulkarn@brownforces.org unconscious force which can block, betray
http://vvk.brownforces.org or countermand almost any conscious
intention of the collective.
-Bene Tleilaxu Theorem
On Mon, 3 May 2004 14:17:11 -0400, Vikram Kulkarni
<vkulkarn@brownforces.org> wrote:
>the end of results/stats.out is:
>-- let stats collector catch up
>SELECT sleep('0:0:2'::interval);
>
>everything up till and including that matches expected/stats.out... but
>the test simply stalls there. Unless I manuall kill the process, the
>postmaster simply keeps soaking up CPU time indefinately.
Please try this interactively in a psql session:
CREATE FUNCTION sleep(interval) RETURNS integer AS '
DECLARE
endtime timestamp;
BEGIN
endtime := timeofday()::timestamp + $1;
WHILE timeofday()::timestamp < endtime LOOP
END LOOP;
RETURN 0;
END;
' LANGUAGE 'plpgsql';
SELECT timeofday();
SELECT timeofday()::timestamp;
-- wait a few seconds ...
SELECT timeofday()::timestamp;
SELECT timeofday()::timestamp + '0:0:2'::interval;
SELECT sleep('0:0:2'::interval);
... and tell us what happens.
On Mon, May 03, 2004 at 11:54:54PM +0200, Manfred Koizar wrote:
> On Mon, 3 May 2004 14:17:11 -0400, Vikram Kulkarni
> <vkulkarn@brownforces.org> wrote:
> >the end of results/stats.out is:
> >-- let stats collector catch up
> >SELECT sleep('0:0:2'::interval);
> >
> >everything up till and including that matches expected/stats.out... but
> >the test simply stalls there. Unless I manuall kill the process, the
> >postmaster simply keeps soaking up CPU time indefinately.
>
> Please try this interactively in a psql session:
>
> CREATE FUNCTION sleep(interval) RETURNS integer AS '
> DECLARE
> endtime timestamp;
> BEGIN
> endtime := timeofday()::timestamp + $1;
> WHILE timeofday()::timestamp < endtime LOOP
> END LOOP;
> RETURN 0;
> END;
> ' LANGUAGE 'plpgsql';
>
> SELECT timeofday();
> SELECT timeofday()::timestamp;
> -- wait a few seconds ...
> SELECT timeofday()::timestamp;
> SELECT timeofday()::timestamp + '0:0:2'::interval;
>
> SELECT sleep('0:0:2'::interval);
>
> ... and tell us what happens.
$ createlang plpgsql test
$ psql test
Welcome to psql 7.4.2, 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
test=# CREATE FUNCTION sleep(interval) RETURNS integer AS '
test'# DECLARE
test'# endtime timestamp;
test'# BEGIN
test'# endtime := timeofday()::timestamp + $1;
test'# WHILE timeofday()::timestamp < endtime LOOP
test'# END LOOP;
test'# RETURN 0;
test'# END;
test'# ' LANGUAGE 'plpgsql';
CREATE FUNCTION
test=# SELECT timeofday();
timeofday
-------------------------------------
Wed Dec 31 16:00:00.591964 1969 PST
(1 row)
test=# SELECT timeofday()::timestamp;
timeofday
----------------------------
1969-12-31 16:00:00.619152
(1 row)
test=# SELECT timeofday()::timestamp;
timeofday
----------------------------
1969-12-31 16:00:00.814891
(1 row)
test=# SELECT timeofday()::timestamp + '0:0:2'::interval;
?column?
----------------------------
1969-12-31 16:00:02.830715
(1 row)
test=# SELECT sleep('0:0:2'::interval);
And it just sits there indefinately...
That obviously doesn't look right. Isnt' timeofday() supposed to return
the current time of day? The system clock is set correctly.
the log file doesn't show anything interesting, except for me eventually
killing the postmaster process... :-\
The config.log is available at:
http://www.brownforces.org/config.log
(I figure that might be interesting...)
-Vik
--
vikram vinayak kulkarni "If you want pasta sauce, you
vkulkarn@brownforces.org must have have pasta."
http://vvk.brownforces.org -Daniel Sachs
On Mon, 3 May 2004 20:47:31 -0400, Vikram Kulkarni <vkulkarn@brownforces.org> wrote: >test=# SELECT timeofday(); > timeofday >------------------------------------- > Wed Dec 31 16:00:00.591964 1969 PST >(1 row) >[...] >That obviously doesn't look right. Isnt' timeofday() supposed to return >the current time of day? The system clock is set correctly. Vik, I guess that on your platform time_t is smaller than long. Please compile and run the attached C program. Servus Manfred
Attachment
On Tue, May 04, 2004 at 10:36:20AM +0200, Manfred Koizar wrote: >On Mon, 3 May 2004 20:47:31 -0400, Vikram Kulkarni wrote: >> >> test=# SELECT timeofday(); >> timeofday >> ------------------------------------- >> Wed Dec 31 16:00:00.591964 1969 PST >> (1 row) >> [...] >> That obviously doesn't look right. Isnt' timeofday() supposed to return >> the current time of day? The system clock is set correctly. > > Vik, I guess that on your platform time_t is smaller than long. Please > compile and run the attached C program. hmmm... on OpenBSD-3.5/sparc64, time_t is an int... http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/include/ansi.h?rev=1.4&content-type=text/x-cvsweb-markup The compiler is GCC 3.3.2 with ProPolice. dt% ./a.out old: >>Wed Dec 31 19:00:00.451903 1969 EST<< new: >>Tue May 04 10:41:12.455457 2004 EDT<< But on my older, OpenBSD-3.1/i386 computer, time_t is defined in the same way, though the compiler is GCC 2.95.3. and the two dates printed there match. hmm... -Vik -- vikram vinayak kulkarni Happiness is a Dunkin Donut. vkulkarn@brownforces.org -Jason Zych http://vvk.brownforces.org
On Tue, 4 May 2004 10:51:30 -0400, Vikram Kulkarni <vkulkarn@brownforces.org> wrote:
>> Vik, I guess that on your platform time_t is smaller than long.
>hmmm... on OpenBSD-3.5/sparc64, time_t is an int...
... which is 32 bit, while long is 64 bit.
>But on my older, OpenBSD-3.1/i386 computer, time_t is defined in the
>same way
On i386 both int and long are 32 bit.
Ok, this is pretty clear now. Apply this patch and recompile Postgres.
diff -ruN ../base/src/backend/utils/adt/nabstime.c src/backend/utils/adt/nabstime.c
--- ../base/src/backend/utils/adt/nabstime.c 2003-09-29 02:05:25.000000000 +0200
+++ src/backend/utils/adt/nabstime.c 2004-05-04 18:05:14.000000000 +0200
@@ -1728,10 +1728,12 @@
char buf[100];
text *result;
int len;
+ time_t tt;
gettimeofday(&tp, &tpz);
+ tt = (time_t) tp.tv_sec;
strftime(templ, sizeof(templ), "%a %b %d %H:%M:%S.%%06d %Y %Z",
- localtime((time_t *) &tp.tv_sec));
+ localtime(&tt));
snprintf(buf, sizeof(buf), templ, tp.tv_usec);
len = VARHDRSZ + strlen(buf);
HTH.
Servus
Manfred
Manfred Koizar <mkoi-pg@aon.at> writes:
>>> Vik, I guess that on your platform time_t is smaller than long.
> Ok, this is pretty clear now. Apply this patch and recompile Postgres.
Yup, that's a gotcha. Patch applied to 7.4 and HEAD branches.
regards, tom lane
Manfred Koizar <mkoi-pg@aon.at> writes:
> I had planned to send a -c diff to -patches, as soon as I have a
> suitable regression test.
Like what? The existing stats test seems to catch this just fine on
machines where the types are actually different sizes. In any case,
I don't necessary believe in memorializing every single bug we ever
find with its own regression case ...
regards, tom lane
On Wed, 05 May 2004 13:30:19 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Yup, that's a gotcha. Patch applied to 7.4 and HEAD branches.
Hey, that was a -r diff. It was not intended for you :-)
I had planned to send a -c diff to -patches, as soon as I have a
suitable regression test. I thought of something like
SELECT timeofday()::timestamp > '2004-05-05'::date;
in horology.
Servus
Manfred