Re: SQL/MED estimated time of arrival?

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

In response to

Browse pgsql-hackers by date

  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