Re: [bug fix] Memory leak in dblink - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [bug fix] Memory leak in dblink
Date
Msg-id 31604.1403191108@sss.pgh.pa.us
Whole thread Raw
In response to Re: [bug fix] Memory leak in dblink  ("MauMau" <maumau307@gmail.com>)
Responses Re: [bug fix] Memory leak in dblink  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
"MauMau" <maumau307@gmail.com> writes:
> From: "Joe Conway" <mail@joeconway.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Atomics hardware support table & supported architectures
Next
From: Joe Conway
Date:
Subject: Re: [bug fix] Memory leak in dblink