Re: SQL/MED estimated time of arrival?
花田 茂 <hanada@metrosystems.co.jp>
From: Shigeru HANADA <hanada@metrosystems.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Hitoshi Harada <umi.tanuki@gmail.com>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, Eric Davies <eric@barrodale.com>, pgsql-hackers@postgresql.org
Date: 2010-11-12T09:12:32Z
Lists: pgsql-hackers
Attachments
- fdw_select_simple_20101112.patch.gz (application/octet-stream) patch
On Mon, 08 Nov 2010 10:31:22 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Shigeru HANADA <hanada@metrosystems.co.jp> writes: > > How about removing them, ConnectServer and FreeFSConnection, from > > FdwRoutine and leaving the responsibility of resource management to > > each FDW? Each FDW would have to use mechanism such as Virtual File > > and ResourceOwner to manage resources properly, though. > > For the most part, we expect that ResourceOwners only do something > useful during error cleanup. That is, you *should* have a > close-connection type of function that is expected to be called during > normal query shutdown. The ResourceOwner hooks will operate to > compensate for the lack of this call in an error recovery case. > The reason for doing things that way is so that we can check for > unintentional resource leakage in the non-error code paths. I fixed postgresql_fdw to use RegisterResourceReleaseCallback() to close all connections in error cases including user interrupt. But I'm not sure if I used the mechanism correctly because all I could find about the API was only few documents, README of resowner and function comments. I tested the codes in cases below and confirmed that all connections have been closed. - remote query error with wrong relation name - user interrupt, Ctrl+C on psql during long query Of course, in non-error case, all connections are closed via normal query shutdown path. During fixing connection cleanup, I've removed connection pooling from postgresql_fdw to make resource management simple. Now postgresql_fdw uses one connection for all of ForeignScan nodes in a local query, but doesn't keep the connection alive beyond queries. Originally, sharing connection is intended to execute multiple remote query in a transaction for consistency. I think external tools such as pgpool or pgbouncer would be better to pool connections. Is it reasonable? Also, ExecInitForeignScan() was fixed to call ConnectServer() and BeginScan() only when the EXEC_FLAG_EXPLAIN_ONLY is not set. Regards, -- Shigeru Hanada