pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Herwig Goemans <herwig.goemans@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Cc: PG Bug reporting form <noreply@postgresql.org>
Subject: Re: BUG #16976: server crash when deleting via a trigger on a foreign table
Date: Wed, 28 Apr 2021 14:24:38 +0200
Message-ID: <d01e4f40-43e6-310a-6f07-d36096ea564d@gmail.com> (raw)
In-Reply-To: <CA+hUKG+XCzNWV82tjgVTUtQ09M6Fuxuow+jCKryPhg+QSo1D_w@mail.gmail.com>
References: <16976-abe0cb88252bc02e@postgresql.org>
	<756273.1619012414@sss.pgh.pa.us>
	<813ebc08-8f81-4efe-a5f2-caac938b7741@gmail.com>
	<CA+hUKG+XCzNWV82tjgVTUtQ09M6Fuxuow+jCKryPhg+QSo1D_w@mail.gmail.com>

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
> <herwig.goemans@gmail.com> 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).





view thread (21+ messages)  latest in thread

Message-ID: <d01e4f40-43e6-310a-6f07-d36096ea564d@gmail.com>
Permalink:  ../d01e4f40-43e6-310a-6f07-d36096ea564d@gmail.com/
Also on:    postgresql.org/message-id/d01e4f40-43e6-310a-6f07-d36096ea564d@gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: herwig.goemans@gmail.com, thomas.munro@gmail.com, tgl@sss.pgh.pa.us, pgsql-bugs@lists.postgresql.org, noreply@postgresql.org
  Subject: Re: BUG #16976: server crash when deleting via a trigger on a foreign table
  In-Reply-To: <d01e4f40-43e6-310a-6f07-d36096ea564d@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox