Re: BUG #16976: server crash when deleting via a trigger on a foreign table

On Thu, May 20, 2021 at 10:57 PM Herwig Goemans
<herwig.goemans@gmail.com> wrote:
> Thank you for your advice, I did as you asked and made a request (31) 8
> days ago but nobody seems to take this issue under his/her care. Is
> there anything that I can do to make someone look at it ?

You could contact the developers, the well known PostgreSQL support
company that owns the repo.

Unfortunately it might be hard to get anyone else to help with it,
because it requires a bunch of non-free software to test, and even if
there are easy-to-install Docker images for that these days, it still
takes time to study how to configure it, and how to install the
proprietary client libraries etc, so you'd probably need someone who
already has such a system running and ready to connect to.  For
example, you :-)

If you can compile informix_fdw yourself (perhaps adding PG_CFLAGS=-g
to its Makefile for better debug information), and post a backtrace as
described earlier, we might be able to guess what's wrong and suggest
some changes you could test, or at least you might be able to add
enough information to the bug report to help it move faster.  Since I
personally have no idea how to drive Ubuntu's core stealing system, I
recommend these steps:

First, connect with psql and find the backend's pid:

postgres=# select pg_backend_pid();
 pg_backend_pid
----------------
        3209646
(1 row)

In another shell windows, connect to that backend with gdb:

$ sudo gdb -p 3209646
...
(gdb)

Tell it to ignore SIGUSR1 (makes things simpler), and then continue:

(gdb) handle SIGUSR1 nostop noprint
Signal        Stop    Print    Pass to program    Description
SIGUSR1       No    No    Yes        User defined signal 1
(gdb) cont
Continuing.

Now back in psql, trigger the problem with your reproducer steps:
postgres=# DELETE ...;

At this point the debugger should show something like this:

Program received signal SIGSEGV, Segmentation fault.
0x00007f5cf5ce60d6 in epoll_wait (epfd=11, events=0x55b7f0fbc088,
maxevents=maxevents@entry=1, timeout=timeout@entry=60000)
    at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
30    in ../sysdeps/unix/sysv/linux/epoll_wait.c
(gdb)

(I don't expect it to show epoll_wait, that's just because I manually
killed a sleeping backend with signal 11 for illustration, but for you
it hopefully shows some code that is trying to access a NULL pointer
or something like that).  That's where you enter "bt" and it prints
out a stack of function calls and line numbers that might help us to
guess what's going wrong.