Re: dblink memory leak - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: dblink memory leak
Date
Msg-id 20091005120001.9CE4.52131E4D@oss.ntt.co.jp
Whole thread Raw
In response to Re: dblink memory leak  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: dblink memory leak  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I think what you want to do instead is use PG_TRY blocks to ensure that
> transient results are cleaned up.

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.
Error and interruption can occur at the caller:
   ExecMakeTableFunctionResult()   {       for (;;)       {
*here*      CHECK_FOR_INTERRUPTS();           result = FunctionCallInvoke(&fcinfo);  => { PG_TRY ... END }           if
(rsinfo.isDone== ExprEndResult)               break;           tuplestore_puttuple(tupstore, &tmptup);       }   }
 

Also, we should think SRF-functions might not be called repeatedly
until max_calls whether the transaction is committed or rollbacked
because we might have some optimization in FunctionScan in the future.
For example:   SELECT * FROM dblink() LIMIT 3
might call dblink() only 3 times if we optimize executor logic
(it should not occur for now, though).

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: dblink memory leak
Next
From: KaiGai Kohei
Date:
Subject: Re: Privileges and inheritance