On 07/08/2019 16:57, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> On 07/08/2019 02:57, Thomas Munro wrote:
>>> On Wed, Jul 24, 2019 at 5:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> So I think I've got to take back the assertion that we've got
>>>> some lurking generic problem. This pattern looks way more
>>>> like a platform-specific issue. Overaggressive OOM killer
>>>> would fit the facts on vulpes/wobbegong, perhaps, though
>>>> it's odd that it only happens on HEAD runs.
>
>>> chipmunk also:
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2019-08-06%2014:16:16
>
>> FWIW, I looked at the logs in /var/log/* on chipmunk, and found no
>> evidence of OOM killings. I can see nothing unusual in the OS logs
>> around the time of that failure.
>
> Oh, that is very useful info, thanks. That seems to mean that we
> should be suspecting a segfault, assertion failure, etc inside
> the postmaster. I don't see any TRAP message in chipmunk's log,
> so assertion failure seems to be ruled out, but other sorts of
> process-crashing errors would fit the facts.
>
> A stack trace from the crash would be mighty useful info along
> about here. I wonder whether chipmunk has the infrastructure
> needed to create such a thing. From memory, the buildfarm requires
> gdb for that, but not sure if there are additional requirements.
It does have gdb installed.
> Also, if you're using systemd or something else that thinks it
> ought to interfere with where cores get dropped, that could be
> a problem.
I think they should just go to a file called "core", I don't think I've
changed any settings related to it, at least. I tried "find / -name
core*", but didn't find any core files, though.
- Heikki