On Wed, Sep 2, 2015 at 6:21 AM, Michael Paquier wrote: > Yes, that's what I have been looking at actually by having some markers in > relcache.c. The reference count of this relation get incremented here:
So, I have been playing more with this code, and as mentioned by Andres this test case goes twice through the PG_CATCH block in pl_exec.c, causing the crash as the temporary relation does not get dereferenced. I may be missing something, but isn't it a matter of moving the switch to the old memory context at the end of the block so as we can get a correct cleanup of the estate in the first block? See for example the attached that fixes the problem for me, and passes make checkworld, though I expect Tom and Andres to jump in and say that this is not correct within the next 12 hours :) I haven't written yet a test case but I think that we could reproduce that simply by having a relation referenced in the exception block of a first function, calling a second function that itself raises an exception, causing the referencing error. Regards, -- Michael
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c index 935fa62..56084c3 100644 --- a/src/pl/plpgsql/src/pl_exec.c +++ b/src/pl/plpgsql/src/pl_exec.c @@ -1253,8 +1253,6 @@ exec_stmt_block(PLpgSQL_execstate *estate, PLpgSQL_stmt_block *block) /* Abort the inner transaction */ RollbackAndReleaseCurrentSubTransaction(); - MemoryContextSwitchTo(oldcontext); - CurrentResourceOwner = oldowner; /* Revert to outer eval_econtext */ estate->eval_econtext = old_eval_econtext; @@ -1326,6 +1324,9 @@ exec_stmt_block(PLpgSQL_execstate *estate, PLpgSQL_stmt_block *block) ReThrowError(edata); else FreeErrorData(edata); + + MemoryContextSwitchTo(oldcontext); + CurrentResourceOwner = oldowner; } PG_END_TRY();
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
