Re: dsa_allocate() faliure - Mailing list pgsql-performance

From Jakub Glapa
Subject Re: dsa_allocate() faliure
Date
Msg-id CAJk1zg0GxWzkh1RESY0=RfoZ_20WaFyt2g7Me=cVr3VYngPthA@mail.gmail.com
Whole thread Raw
In response to Re: dsa_allocate() faliure  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: dsa_allocate() faliure  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-performance
Justin thanks for the information! 
I'm running Ubuntu 16.04. 
I'll try to prepare for the next crash. 
Couldn't find anything this time.


--
regards,
Jakub Glapa


On Mon, Nov 26, 2018 at 4:52 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
Hi, thanks for following through.

On Mon, Nov 26, 2018 at 04:38:35PM +0100, Jakub Glapa wrote:
> I had a look at dmesg and indeed I see something like:
>
> postgres[30667]: segfault at 0 ip 0000557834264b16 sp 00007ffc2ce1e030
> error 4 in postgres[557833db7000+6d5000]

That's useful, I think "at 0" means a null pointer dereferenced.

Can you check /var/log/messages (or ./syslog or similar) and verify the
timestamp matches the time of the last crash (and not an unrelated crash) ?

The logs might also indicate if the process dumped a core file anywhere.

I don't know what distribution/OS you're using, but it might be good to install
abrt (RHEL) or apport (ubuntu) or other mechanism to save coredumps, or to
manually configure /proc/sys/kernel/core_pattern.

On centos, I usually set:
/etc/abrt/abrt-action-save-package-data.conf
OpenGPGCheck = no

Also, it might be good to install debug symbols, in case you do find a core
dump now or get one later.

On centos: yum install postgresql10-debuginfo or debuginfo-install postgresql10-server
Make sure this exactly matches the debug symbols exactly match the server version.

Justin

pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Optimizer choosing the wrong plan
Next
From: Tom Lane
Date:
Subject: Re: autovacuum run but last_autovacuum is empty