Re: Why is parula failing?

Robins Tharakan <tharakan@gmail.com>

From: Robins Tharakan <tharakan@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Tomas Vondra <tomas.vondra@enterprisedb.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-15T04:09:55Z
Lists: pgsql-hackers

Attachments

On Sun, 14 Apr 2024 at 00:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?

- I now have 2 separate runs stuck on pg_sleep() - HEAD / REL_16_STABLE
- I'll keep them (stuck) for this week, in case there's more we can get
from them (and to see how long they take)
- Attached are 'bt full' outputs for both (b.txt - HEAD / a.txt -
REL_16_STABLE)

A few things to add:
- To reiterate, this instance has gcc v13.2 compiled without any
flags (my first time ever TBH) IIRC 'make -k check' came out okay,
so at this point I don't think I did something obviously wrong when
building gcc from git.
- I installed gcc v14.0.1 experimental on massasauga (also an aarch64
and built from git) and despite multiple runs, it seems to be doing okay
[1].
- Next week (if I'm still scratching my head - and unless someone advises
otherwise), I'll upgrade parula to gcc 14 experimental to see if this is
about
gcc maturity on graviton (for some reason). I don't expect much to come
out of it though (given Tomas testing on rpi5, but doesn't hurt)

Ref:
1.
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=massasauga&br=REL_12_STABLE

-
robins

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