Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZWHO-0004Tp-CO for pgsql-bugs@arkaria.postgresql.org; Thu, 22 Apr 2021 10:09:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lZWHN-0006El-9K for pgsql-bugs@arkaria.postgresql.org; Thu, 22 Apr 2021 10:09:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZWHN-0006Ed-0o for pgsql-bugs@lists.postgresql.org; Thu, 22 Apr 2021 10:09:49 +0000 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lZWHK-0002Vf-Jo for pgsql-bugs@lists.postgresql.org; Thu, 22 Apr 2021 10:09:47 +0000 Received: by mail-ed1-x52f.google.com with SMTP id bx20so51607248edb.12 for ; Thu, 22 Apr 2021 03:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=b2T+OgTCsUqGHKtuFYPWUaW6Jz+RtF8lYbBN5Qv7tL0=; b=qh0lU3D1K7fA1wLI6MuaAOcu1m8ykrN1P/c3M8j1CwcOe8OARXxBqHlhZDOOwQCFHF VJmJHm8QpOJBiQiMWCXJxFjFoLeaLIc63XV00rCYH0nkChxUcP6uS6goECemXowUMjqh RJbie/dKcgOjHcngeRtcSWqDzXsa/jbK+7GlRcqe9x23ecpiGAKMyKrpJiVtuMgCgcLq 37odNcNcXEDnqhatbEJp0SrRIYwMumKhR3oSlOMIjEA6luKraLQ0YpWVHZHu2NlljXu0 m3oXwk1VZdZs8AE6vZqMlSqW1S/NG9plmJiN9yJRc2n/x7n8W6NP/alcdFjD3AA+Tll8 LZOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=b2T+OgTCsUqGHKtuFYPWUaW6Jz+RtF8lYbBN5Qv7tL0=; b=Lb/UQunfkrNkFbz9PUS7iKmqR+Oc9Mwf1kCC/FLS4SC6TmMt3pKF8kGsnRxkC8rfxK sf/zSlR1Cbi1c75C509qIpkbRBHjS8PIIpZM7+O8l8BSFfOYTOod7nRdI2lHC3r6iTV5 Q47jCVMRnFieOL+Sw3eIXcCWuuTcbp9Ibszpaq+jDev9uBJW93ehnjeu+nvTITx+QvZO kVisdDYH5ND5VOo4PEM95zkbyRdAo7+nhzBenNOmAHGWIWOj4r4oNygwFt+3SBAlDait gOPnJKU/zjk/G3zvY8M4LRP/8bF9FBnLoPOUpIrcuDh10MJ/Ba0tl4eUxkADb2HUMhkU vLHA== X-Gm-Message-State: AOAM533DgIn03UGLPB8zRsGkbwgiFwVWhKgvRHdTAfwMCWtXy1hyIzBJ +WZaMAkvhQHzKOHTe17qw/OXEeZrp0k= X-Google-Smtp-Source: ABdhPJxfPBti3aKalKemNw45PNncWRP9+j25PvSdnolm9aShFIQdqha2wteFpzob1BtSrtVodjhVuw== X-Received: by 2002:aa7:c7cc:: with SMTP id o12mr2869723eds.291.1619086184927; Thu, 22 Apr 2021 03:09:44 -0700 (PDT) Received: from [192.168.178.48] ([212.71.9.13]) by smtp.gmail.com with ESMTPSA id f25sm1678300eds.73.2021.04.22.03.09.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Apr 2021 03:09:44 -0700 (PDT) Subject: Re: BUG #16976: server crash when deleting via a trigger on a foreign table To: Tom Lane , pgsql-bugs@lists.postgresql.org, PG Bug reporting form References: <16976-abe0cb88252bc02e@postgresql.org> <756273.1619012414@sss.pgh.pa.us> From: Herwig Goemans Message-ID: <813ebc08-8f81-4efe-a5f2-caac938b7741@gmail.com> Date: Thu, 22 Apr 2021 12:09:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <756273.1619012414@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: nl-BE List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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