From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Eric Davies <eric(at)barrodale(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL/MED estimated time of arrival? |
Date: | 2010-11-06 15:29:29 |
Message-ID: | 19495.1289057369@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
> And if we really make this async query come true, I suggest designing
> resource (i.e. remote connection) management very carefully. When the
> executor fails in the middle of its execution, it possibly fails to
> release its own resource; close() in ExecutorEnd() will never be
> called. As far as I know files and memory are released automatically
> in the current mechanism, but MED APIs will use their own resources
> other than them.
The way to fix that is for the FDW to hook into the ResourceOwner
mechanism (via RegisterResourceReleaseCallback). Then it can track
and clean up things it knows about just as "automatically" as anything
else is.
Of course, if you lose your network connection to the remote DB,
you have to assume it will clean up of its own accord.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-11-06 15:31:41 | PL/pgSQL and shared_preload_libraries |
Previous Message | Yeb Havinga | 2010-11-06 14:53:14 | Re: Fix for seg picksplit function |