From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "MauMau" <maumau307(at)gmail(dot)com> |
Cc: | "Joe Conway" <mail(at)joeconway(dot)com>, "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [bug fix] Memory leak in dblink |
Date: | 2014-06-19 15:18:28 |
Message-ID: | 31604.1403191108@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"MauMau" <maumau307(at)gmail(dot)com> writes:
> From: "Joe Conway" <mail(at)joeconway(dot)com>
>> Any objections to me back-patching it this way?
> I thought the same at first before creating the patch, but I reconsidered.
> If the query executed by dblink() doesn't return any row, the context
> creation and deletion is a waste of processing. I think the original author
> wanted to eliminate this waste by creating the context when dblink() should
> return a row. I'd like to respect his thought.
I don't think speed is really worth worrying about. The remote query will
take orders of magnitude more time than the possibly-useless context
creation.
The code is really designed to put all the setup for storeRow into one
place; but I concur with Joe that having teardown in a different place
from setup isn't very nice.
An alternative that might be worth thinking about is putting both the
context creation and deletion at the outermost level where the storeInfo
struct is defined. That seems possibly a shade less surprising than
having it at the intermediate level.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2014-06-19 15:40:02 | Re: [bug fix] Memory leak in dblink |
Previous Message | Alvaro Herrera | 2014-06-19 15:00:51 | Re: Atomics hardware support table & supported architectures |