Re: Why is lorikeet so unstable in v14 branch only?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Why is lorikeet so unstable in v14 branch only?
Date: 2022-03-26 21:48:39
Message-ID: 0b9defaa-07a3-7329-4f9d-5fc2c4a89170@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 3/26/22 17:19, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-03-26 21:52:23 Re: pg_stat_get_replication_slot() marked not strict, crashes
Previous Message Tom Lane 2022-03-26 21:41:53 Re: pg_stat_get_replication_slot() marked not strict, crashes