From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Przemysław Szustak <przemyslaw(dot)szustak(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16283: crash on create index segmentation fault |
Date: | 2020-02-28 21:00:21 |
Message-ID: | 20200228210021.znum3xr3kprj3qec@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Feb 28, 2020 at 08:58:19PM +0100, Przemysław Szustak wrote:
>I updated info on github logs because now system was generated new core
>dump.
>
>How can I get you more information? I don't now how to debug it.
>
Well, it's hard to say what exactly is happening, without getting a
better backtrace. Your system is apparently missing debug symbols, so
you need to do something like
sudo aptitude install postgresql-10-dbg
or something like that. And the same for postgis, I assume. Then
generate the backtrace again (using the existing core file).
You might also attach gdb to the running backend, trigger the issue
and do more investigation there.
1) determine the PID of the backend handling your connection
db=# select pg_backend_pid();
2) attach GDB to the process
$ gdb -p $PID
(gdb) c
3) Run the query using the same backend, once it triggers you'll be able
to do 'bt' in the gdb shell and inspect variables.
This needs the debug symbols too, though.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-02-28 23:21:38 | Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema |
Previous Message | Daniel Gustafsson | 2020-02-28 20:33:55 | Re: BUG #16274: Repeated Libraries in Mac |