Re: bug or simply not enough stack space?

From: Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
To: pgsql-bugs(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: bug or simply not enough stack space?
Date: 2009-07-17 09:10:57
Message-ID: 200907171110.58371.ftm.van.vugt@foxi.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Ok,

So this took a while, but here's your test case.....
Turns out to be quite small actually ;)

create table t1 (id int);

CREATE FUNCTION tr_t1_after_iud()
RETURNS trigger
LANGUAGE 'plpgsql'
VOLATILE
STRICT
SECURITY INVOKER
AS 'DECLARE
BEGIN
RAISE NOTICE ''%'', ROW(NEW.*);
SELECT 1/0;
RETURN NEW;
END;';

CREATE TRIGGER t1_after AFTER INSERT OR UPDATE OR DELETE ON t1 FOR EACH ROW
EXECUTE PROCEDURE tr_t1_after_iud();

begin;

savepoint s1;

INSERT INTO t1 values (1);

=> this will result in the following:

db=# INSERT INTO t1 values (1);
NOTICE: (1)
WARNING: AbortSubTransaction while in ABORT state
WARNING: did not find subXID 77063 in MyProc
ERROR: division by zero
CONTEXT: SQL statement "SELECT 1/0"
PL/pgSQL function "tr_t1_after_iud" line 4 at SQL statement
ERROR: tupdesc reference 0x7ffe74f24ad0 is not owned by resource owner
SubTransaction

=> mind the fact that the savepoint is 'needed', without it there will be no
problem

=> in my reallife example, this resulted in a "PANIC: ERRORDATA_STACK_SIZE
exceeded", I cannot reproduce that, but as you stated earlier, this might just
be collateral damage, which I'll be able to easily confirm once the problem
above has been fixed.

=> cleanup:

rollback;
drop table t1;
drop function tr_t1_after_iud();

=> to avoid possible confusion

db=# select version();
version
---------------------------------------------------------------------------------------
PostgreSQL 8.4.0 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.2.4, 64-bit

Looking forward to your reply.

--
Best,

Frank.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mikael Krantz 2009-07-17 09:45:47 Re: Huge speed penalty using <>TRUE instead of =FALSE
Previous Message Heikki Linnakangas 2009-07-17 08:56:51 Re: BUG #4926: too few pathkeys for mergeclauses