Re: Collection of memory leaks for ECPG driver

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Michael Meskes <meskes(at)postgresql(dot)org>
Subject: Re: Collection of memory leaks for ECPG driver
Date: 2015-06-14 11:43:13
Message-ID: CAB7nPqRbG4C3LMZk1U_j-E2k4T1_6wwR9foqyExNF_T4eh8zrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jun 13, 2015 at 6:25 PM, Michael Meskes <meskes(at)postgresql(dot)org> wrote:
> On Sat, Jun 13, 2015 at 12:02:40AM -0400, Tom Lane wrote:
>> But having said that, I would not be in a hurry to remove any existing
>> if-guards for the case. For one thing, it makes the code look more
>> similar to backend code that uses palloc/pfree, where we do *not* allow
>> pfree(NULL). There's also the point that changing longstanding code
>> creates back-patching hazards, so unless there's a clear gain it's best
>> not to.
>
> Makes sense, but there is no point in adding hos if-guards to old code that
> doesn't have it either,right?

In any case, whatever the final decision done here, I just wanted to
point out that there is still a leak in connect.c. Per se the attached
patch, that does not check for a NULL pointer before ecpg_free because
other code paths in the routine patched don't do so. So you get
something locally consistent ;)
--
Michael

Attachment Content-Type Size
20150614_ecpg_leaks_v3.patch text/x-diff 484 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-06-14 12:22:10 Re: 9.5 release notes
Previous Message Thom Brown 2015-06-14 11:31:26 Re: Problem with CREATE TABLE ... (LIKE ... INCLUDING INDEXES)