Re: Why is parula failing? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why is parula failing?
Date
Msg-id 61593.1713019366@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why is parula failing?  (Robins Tharakan <tharakan@gmail.com>)
Responses Re: Why is parula failing?
List pgsql-hackers
Robins Tharakan <tharakan@gmail.com> writes:
> HEAD is stuck again on pg_sleep(), no CPU for the past hour or so.
> Stack trace seems to be similar to last time.

> #3  0x00000000008437c4 in WaitLatch (latch=<optimized out>,
> wakeEvents=wakeEvents@entry=41, timeout=600000,
> wait_event_info=wait_event_info@entry=150994946) at latch.c:538
> #4  0x000000000090c384 in pg_sleep (fcinfo=<optimized out>) at misc.c:406
> ...
> #17 0x000000000086f5d4 in exec_simple_query
> (query_string=query_string@entry=0x3b391c90
> "SELECT pg_sleep(0.1);") at postgres.c:1274

If we were only supposed to sleep 0.1 seconds, how is it waiting
for 600000 ms (and, presumably, repeating that)?  The logic in
pg_sleep is pretty simple, and it's hard to think of anything except
the system clock jumping (far) backwards that would make this
happen.  Any chance of extracting the local variables from the
pg_sleep stack frame?

            regards, tom lane



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: sql/json remaining issue
Next
From: Tom Lane
Date:
Subject: Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)