Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> The following testcase(extracted from a much much larger production code
> sample) results in
> WARNING: TupleDesc reference leak: TupleDesc 0xb3573b88 (2249,1) still
> referenced
> CONTEXT: PL/pgSQL function "foo" line 4 at block variables initialization
> ERROR: tupdesc reference 0xb3573b88 is not owned by resource owner Portal
> CONTEXT: PL/pgSQL function "foo" while casting return value to
> function's return type
Hmm. What's happening is that the record-function call creates a
reference-counted TupleDesc, and tracking of the TupleDesc is
assigned to the subtransaction resource owner because we're inside
an EXCEPTION-block subtransaction. But the pointer is held by the
function's eval_context which lives throughout the function call,
and so the free happens long after exiting the subtransaction, and
the resource owner code quite properly complains about this.
In this particular case the worst consequence would be a short-term
memory leak, but I think there are probably variants with worse
problems, because anything done by a RegisterExprContextCallback()
callback is equally at risk.
I think the proper fix is probably to establish a new eval_context
when we enter an EXCEPTION block, and destroy it again on the way out.
Slightly annoying, but probably small next to the other overhead of
a subtransaction. Comments?
BTW, both of the CONTEXT lines are misleading. The WARNING happens
during exit from the begin-block, not entry to it; and the ERROR
happens after we've finished fooling with the result value. I'm
tempted to add a few more assignments to err_text to make this nicer.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
