From: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: dblink memory leak |
Date: | 2009-10-05 03:12:55 |
Message-ID: | 20091005120001.9CE4.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2009-10-05 03:15:02 | Re: Privileges and inheritance |
Previous Message | Tom Lane | 2009-10-05 02:53:02 | Re: dblink memory leak |