Re: minor leaks in pg_dump (PG tarball 10.6)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Pavel Raiskup <praiskup(at)redhat(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: minor leaks in pg_dump (PG tarball 10.6)
Date: 2018-12-05 16:06:48
Message-ID: 4087.1544026008@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Pavel Raiskup (praiskup(at)redhat(dot)com) wrote:
>> - attrdefs = (AttrDefInfo *) pg_malloc(numDefaults * sizeof(AttrDefInfo));
>> ...
>> + attrdefs = (AttrDefInfo *) pg_malloc(numDefaults * sizeof(AttrDefInfo));

> This change doesn't seem to make any sense to me..? If anything, seems
> like we'd end up overallocating memory *after* this change, where we
> don't today (though an analyzer tool might complain because we don't
> free the memory from it and instead copy the pointer from each of these
> items into the tbinfo structure).

Yeah, Coverity is exceedingly not smart about the method pg_dump uses
(in lots of places, not just here) of allocating an array and then
entering pointers to individual array elements into its long-lived
data structures. I concur that the proposed change is giving up a
lot of malloc overhead to silence an invalid complaint, and we
shouldn't do it.

The other two points seem probably valid, so I wonder why our own
Coverity runs haven't noticed them.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-12-05 16:09:54 Re: psql display of foreign keys
Previous Message Stephen Frost 2018-12-05 15:59:18 Re: minor leaks in pg_dump (PG tarball 10.6)