Re: Why is parula failing?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robins Tharakan <tharakan@gmail.com>
Cc: "Tharakan, Robins" <tharar@amazon.com>, David Rowley <dgrowleyml@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-13T14:42:46Z
Lists: 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



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Revert "Temporarily install debugging in partition_prune test"

  2. Temporarily install debugging in partition_prune test

  3. Review wording on tablespaces w.r.t. partitioned tables