Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group