Re: bug or simply not enough stack space? - Mailing list pgsql-bugs

From Frank van Vugt
Subject Re: bug or simply not enough stack space?
Date
Msg-id 200907171110.58371.ftm.van.vugt@foxi.nl
Whole thread Raw
In response to Re: bug or simply not enough stack space?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: bug or simply not enough stack space?
List 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.

pgsql-bugs by date:

Previous
From: Jan-Ivar Mellingen
Date:
Subject: Huge speed penalty using <>TRUE instead of =FALSE
Next
From: Peter Eisentraut
Date:
Subject: Re: Huge speed penalty using <>TRUE instead of =FALSE