Re: [bug fix] Memory leak in dblink

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

In response to

Responses

Browse pgsql-hackers by date

  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