Re: Anti-critical-section assertion failure in mcxt.c reached by walsender - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Anti-critical-section assertion failure in mcxt.c reached by walsender
Date
Msg-id d4e4c66f-9363-5a52-1178-2ff41e3fcc8c@dunslane.net
Whole thread Raw
In response to Re: Anti-critical-section assertion failure in mcxt.c reached by walsender  (Andres Freund <andres@anarazel.de>)
Responses Re: Anti-critical-section assertion failure in mcxt.c reached by walsender
List pgsql-hackers
On 5/7/21 12:38 AM, Andres Freund wrote:
> Hi,
>
> On 2021-05-07 00:30:11 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> On 2021-05-06 21:43:32 -0400, Tom Lane wrote:
>>>> That I'm not sure about.  gdb is certainly installed, and thorntail is
>>>> visibly running the current buildfarm client and is configured with the
>>>> correct core_file_glob, and I can report that the crash did leave a 'core'
>>>> file in the data directory (so it's not a case of systemd commandeering
>>>> the core dump).  Seems like core-file collection should've worked
>>>> ... unless maybe it's not covering TAP tests at all?
>>> I suspect that is it - there's not really a good way for the buildfarm
>>> client to even know where there could be data directories :(.
>> Does it need to?  I'm envisioning "find tmp_check -name '$core_file_glob'"
>> or something along that line.
> Yea, it'd be doable that way. It'd be a bit harder to associate the core
> files with specific tests though. But I now checked, and it indeed
> checks for core files in a specific subset of tests, and that that test
> only globs inside the passed-in datadir.
>

working on it ...


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: cache lookup failed for statistics object 123
Next
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.