Re: dblink memory leak

On Mon, Oct 5, 2009 at 1:46 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> Tom Lane wrote:
>> Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
>>> I think PG_TRY blocks are not enough, too. PG_TRY requires a statement
>>> block, but we need to return from dblink functions per tuple.
>>
>> That bit will have to be undone.  There is no reason for dblink not to
>> return a tuplestore.
>
> That's a really good point. It was originally written thinking we would
> eventually be able to stream tuples rather than materialize them, but
> given that many years have passed and we are no closer (I believe) to a
> true streaming mode for SRFs, a tuplestore would be much cleaner.
>
> Given that change, is there even any leak to even worry about? As long
> as the PGresult object is created in the correct memory context, it
> ought to get cleaned up automatically, no?
>
> I can't promise to make this change before 15 October, but I will get to
> it before the end of CF3.

Another possibility is that Itagaki Takahiro, who developed the
original patch, might be willing to develop something along these
lines instead.

However, it does seem that that original patch will not be accepted,
for the reason that the committers prefer the approach discussed
upthread. Therefore, I am marking the "query cancel issues in dblink"
patch as "Returned with Feedback".

...Robert