Re: Why is lorikeet so unstable in v14 branch only?
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2022-03-26T21:48:39Z
Lists: pgsql-hackers
On 3/26/22 17:19, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> On 3/26/22 15:49, Andres Freund wrote: >>> One interesting bit in the config is: >>> [ lack of ] >>> 'update_process_title = off' >> I'd forgotten about that. Let me do that for REL_14_STABLE and see where >> we get to. > Hm. But if that does mitigate it, it still seems like a bug no? > Why would that be preferentially crashing partitioned-table creation? Yes it seems like a bug, but hard to diagnose. It seemed like a bug back in May: see <https://postgr.es/m/4baee39d-0ebe-8327-7878-5bc11c95effa@dunslane.net> I vaguely theorize about a buffer overrun somewhere that scribbles on the stack. The answer to Andres's question about where the stackdumps go is that they go in the data directory, AFAIK. You can see the buildfarm logic for collecting them at <https://github.com/PGBuildFarm/client-code/blob/main/PGBuild/Utils.pm> starting at line 149. There are various appropriate invocations of get_stack_trace() in run_build.pl. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Commits
-
Fix breakage of get_ps_display() in the PS_USE_NONE case.
- 9016a2a3dc4e 13.7 landed
- 3f7a59c59b48 14.3 landed
- 0fb6954aa501 15.0 landed