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 1lbjFD-0000w4-0h for pgsql-bugs@arkaria.postgresql.org; Wed, 28 Apr 2021 12:24:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lbjFB-00037m-VB for pgsql-bugs@arkaria.postgresql.org; Wed, 28 Apr 2021 12:24:41 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lbjFB-00037f-MK for pgsql-bugs@lists.postgresql.org; Wed, 28 Apr 2021 12:24:41 +0000 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lbjF9-0003vQ-PN for pgsql-bugs@lists.postgresql.org; Wed, 28 Apr 2021 12:24:41 +0000 Received: by mail-ed1-x52e.google.com with SMTP id j28so9945387edy.9 for ; Wed, 28 Apr 2021 05:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=KMRdZZmdlIRU2JcreFg9ljwKYqpaLlaRbL4kvLiOCXs=; b=EQMcyKmKtQz3KclkQXHhFEk/+eVqX8q+0BD9X2ADch0xtQkvF5ntJIK2X45mJPQLTm XP01cAns9yNODd4RoInfwuBoOqJuicwuCbH+OwzheAb6NKbgqHcFIJP2bRM2na9VrUgX Z1XJqDvYU0sdrs+z0Q1/s3g1r/LHa4NsrmFAgtB3IsAj5PXUWjeDJ4pPKz+YQ8wH56Iz yl3bCEgQyrwp6jK0tShv6FwHzBMgxyekzs9JFKKOxA1hb8kQxyu9d5x1qaYlfmo7EHlX pbxbZrcYYwr42ydwu5m2hJJ0eL99ScOE77wtwTnPus6snoppMxKPIgun5CYaIA4yKWUv onYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KMRdZZmdlIRU2JcreFg9ljwKYqpaLlaRbL4kvLiOCXs=; b=MRFpcBUN5A25o1Gqfavk2oAOMbT3xH00EN8qkFhpHF2J1K9O+MTyujp06M37PE4d78 YK+4k6fcmrXjHqLCdapCDrkNDjWRmJmeclQftlMMaO+AmUOVs/sAUYzBKhVbxoiPxcZz GYRntMhkLK3RGHb8sx3qHzqXLh1divgPJ9BzBqqmuQ5jeIcGTaTHcSFLjCELS3WX0VOh 9IwHkhfseH7l6Q5wTGzX3Z6i3zYg9H1a/FA5lT4RbKE3PkxUkPr5OSjiYOwePnAfGvou aLKU5w+IHjCHnPvf6DcTr1r+ka6M9eRvCo8Fcr6X6gkqap6O3gvf7iuLPEBVNJ99o8+H 3/EQ== X-Gm-Message-State: AOAM533tBwZ584PuQJo8vHG7v7+mBrYZLeSlv7HjvMrlH+/49xcqSISF 4aLYjsIv7haDvM89Un6rbFg= X-Google-Smtp-Source: ABdhPJx3fjxVx+HvaH7Bpa9VpuFTZY/PHyz6mkj0qhPH9OHcm5OwAbaMvxxNXHgvt6i8KmLdLkI2Rw== X-Received: by 2002:aa7:cf12:: with SMTP id a18mr4024966edy.160.1619612678658; Wed, 28 Apr 2021 05:24:38 -0700 (PDT) Received: from [192.168.178.48] ([212.71.9.13]) by smtp.gmail.com with ESMTPSA id dv22sm1830022ejb.111.2021.04.28.05.24.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Apr 2021 05:24:38 -0700 (PDT) Subject: Re: BUG #16976: server crash when deleting via a trigger on a foreign table To: Thomas Munro Cc: Tom Lane , PostgreSQL mailing lists , PG Bug reporting form References: <16976-abe0cb88252bc02e@postgresql.org> <756273.1619012414@sss.pgh.pa.us> <813ebc08-8f81-4efe-a5f2-caac938b7741@gmail.com> From: Herwig Goemans Message-ID: Date: Wed, 28 Apr 2021 14:24:38 +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: 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 Support, The problem is  in ifx_fdw.c but I do not have dbg packages installed for this nor do I know where to find these for ubuntu. But is there no way you can simulate this issue ? There is a PG server crash due to bad user code in a trigger function. In the mean time we found out that the user code in the trigger function was wrong: it has to work with old instead of new values:      delete from informix.t_water_eenheid                 where enh_id = old.enh_id;                 return old; instead of:                 delete from informix.t_water_eenheid                 where enh_id = new.enh_id;                 return new; using old it works fine. But regardless, the PG server should not crash due to bad user code. I suppose you agree. I only work 2 days a week for this client and this is taking up much of my time so I was hoping you could simulate this. Kind regards, Herwig On 23/04/2021 00:45, Thomas Munro wrote: > On Thu, Apr 22, 2021 at 10:09 PM Herwig Goemans > wrote: >> And I cannot execute anything in the attached (psql) process, > A couple of notes about the attach-then-crash approach: It should be > "postgres", not "psql", that you attach to, and then you need to type > "cont" to tell the debugger to allow execution to continue, or it'll > just block as you described. Sometimes it will stop execution when > signals arrive, and you can disable that with eg "handle SIGUSR1 > nostop" and then go back to executing with "cont" again. Once you > make it crash, you'll be able to use "bt" to see exactly where, but as > mentioned it'll just be a bunch of big hex numbers unless the symbols > are installed; at the least it'll show which modules (postgres, > informix_fdw.so or such).