From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: possible connection leak in dblink? |
Date: | 2011-06-25 20:36:33 |
Message-ID: | 4E0646D1.7070409@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/14/2011 07:41 PM, Fujii Masao wrote:
> On Wed, Jun 15, 2011 at 5:34 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> Otherwise the connection might not get freed. Could someone verify
>> that?
>
> ISTM that the root problem is that dblink_send_query calls DBLINK_GET_CONN
> though it doesn't accept the connection string as an argument. Since the first
> argument in dblink_send_query must be the connection name, dblink_send_query
> should call DBLINK_GET_NAMED_CONN instead. The variable 'freeconn' is used
> only when DBLINK_GET_CONN is called. So, if dblink_send_query uses
> DBLINK_GET_NAMED_CONN instead, the variable 'freeconn' is no longer necessary.
>
> The similar problem exists in dblink_get_result and dblink_record_internal.
> Attached patch fixes those problems.
Fujii's assessment looks correct, although arguably the change is
unnecessary for dblink_record_internal.
Looks like the issue with dblink_send_query goes back through 8.4, while
dblink_record_internal could be fixed as far back as 8.2.
However, since this is really just a case of unused variables and not a
leaked connection, I'm inclined to just fix git master -- comments on that?
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-06-25 21:11:48 | Re: possible connection leak in dblink? |
Previous Message | Kevin Grittner | 2011-06-25 19:29:38 | Re: Repeated PredicateLockRelation calls during seqscan |