Re: Why is parula failing?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robins Tharakan <tharakan(at)gmail(dot)com>
Cc: "Tharakan, Robins" <tharar(at)amazon(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Why is parula failing?
Date: 2024-04-13 14:42:46
Message-ID: 61593.1713019366@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robins Tharakan <tharakan(at)gmail(dot)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(at)entry=41, timeout=600000,
> wait_event_info=wait_event_info(at)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(at)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-04-13 14:53:53 Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)
Previous Message jian he 2024-04-13 14:12:47 Re: sql/json remaining issue