On Sat, Jun 13, 2015 at 6:25 PM, Michael Meskes <mes...@postgresql.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
diff --git a/src/interfaces/ecpg/ecpglib/connect.c b/src/interfaces/ecpg/ecpglib/connect.c
index 55c5680..e45d17f 100644
--- a/src/interfaces/ecpg/ecpglib/connect.c
+++ b/src/interfaces/ecpg/ecpglib/connect.c
@@ -321,7 +321,10 @@ ECPGconnect(int lineno, int c, const char *name, const char *user, const char *p
}
if ((this = (struct connection *) ecpg_alloc(sizeof(struct connection), lineno)) == NULL)
+ {
+ ecpg_free(dbname);
return false;
+ }
if (dbname != NULL)
{
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
