Re: dblink memory leak - Mailing list pgsql-hackers

From Robert Haas
Subject Re: dblink memory leak
Date
Msg-id 603c8f070910051748k25b60d69i997269b2403d33da@mail.gmail.com
Whole thread Raw
In response to Re: dblink memory leak  (Joe Conway <mail@joeconway.com>)
Responses Re: dblink memory leak  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
On Mon, Oct 5, 2009 at 1:46 PM, Joe Conway <mail@joeconway.com> wrote:
> Tom Lane wrote:
>> Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.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


pgsql-hackers by date:

Previous
From: Euler Taveira de Oliveira
Date:
Subject: Re: moving system catalogs to another tablespace
Next
From: Robert Haas
Date:
Subject: Re: Lock Wait Statistics (next commitfest)