Tom Lane wrote:
> 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?
we use exception blocks heavily here so anything that makes them slower
is not nice but if it fixes the issue at hand I'm all for it ...
>
> 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.
yeah wondered about that too when I tried to produce a simple testcase -
the errors did't seem to make much sense in the context of what
triggered them. Improving that would be a very godd thing to do.
Stefan
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
