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