Hi,
I tried it again. With a previous test the trigger did not exists, that
is why it worked.
Anyway, with the trigger in place we encounter PG server crashes.
I am having trouble collection a trace file because when I attach gdb to
the process:
0x00007f99b46f7a07 in epoll_wait (epfd=5, events=0x561321b40630,
maxevents=maxevents@entry=1, timeout=timeout@entry=-1) at
../sysdeps/unix/sysv/linux/epoll_wait.c:30
30 ../sysdeps/unix/sysv/linux/epoll_wait.c: No such file or directory.
(gdb) quit
or
Reading symbols from /lib/x86_64-linux-gnu/libnss_files.so.2...Reading
symbols from
/usr/lib/debug//lib/x86_64-linux-gnu/libnss_files-2.27.so...done.
done.
0x00007fd77dc3343e in __libc_read (fd=0, buf=0x7ffc49e20010, nbytes=1)
at ../sysdeps/unix/sysv/linux/read.c:27
27 ../sysdeps/unix/sysv/linux/read.c: No such file or directory.
(gdb) quit
A debugging session is active.
Inferior 1 [process 35694] will be detached.
And I cannot execute anything in the attached (psql) process,
it complains about a file not found , always in sysdeps. ( i do not find
this directory on the server)
Anyway when the trigger is fired, it crashes the server.
I can delete on the foreign table directly and I can delete on the
foreign table with a function that returns void instead of trigger. all
that works fine.
The function is:
CREATE OR REPLACE FUNCTION metadblucht.test_herwig(p_enh_id int)
RETURNS void
LANGUAGE plpgsql
AS $function$
BEGIN
delete from informix.t_water_eenheid
where enh_id = p_enh_id;
END;
$function$
;
When I run this function, it works fine.
SELECT metadblucht.test_herwig(38);
and the record is deleted from the foriegn table.
I can delete from the foreign table directly:
delete from informix.t_water_eenheid where enh_id = 40;
that works fine as well.
Can you continue zith this information or do you still need the trace
file. I have no idea what I can do to resolve the issue with sysdeps not
on the server.
Kind regards,
Herwig
On 21/04/2021 15:40, Tom Lane wrote:
>> I have experienced a server crash when deleting from a table that ahs a
>> before trigger on it. The before trigger calls a function that deletes from
>> a foreign (informix) table.
> Hm, can you get a stack trace from that?
>
> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
>
> It seems fairly likely that the bug is in whatever FDW you're using
> rather than in core Postgres. A stack trace would help to
> confirm or refute that.
>
> regards, tom lane
