Re: Fixing memory leak in pg_upgrade - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Fixing memory leak in pg_upgrade
Date
Msg-id 20150109172759.GB26812@momjian.us
Whole thread Raw
In response to Re: Fixing memory leak in pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixing memory leak in pg_upgrade
List pgsql-hackers
On Fri, Jan  9, 2015 at 11:34:24AM -0500, Tom Lane wrote:
> Tatsuo Ishii <ishii@postgresql.org> writes:
> > According to Coverity, there's a memory leak bug in transfer_all_new_dbs().
>
> It's pretty difficult to get excited about that; how many table-free
> databases is pg_upgrade likely to see in one run?  But surely we could
> just move the pg_free call to after the if-block.

I have fixed this with the attached, applied patch.  I thought malloc(0)
would return null, but our src/common pg_malloc() has:

    /* Avoid unportable behavior of malloc(0) */
    if (size == 0)
        size = 1;

so some memory is allocated, and has to be freed.  I looked at avoiding
the call to gen_db_file_maps() for old_db->rel_arr.nrels == 0, but there
are checks in there comparing the old/new relation counts, so it can't
be skipped.  I also removed the unnecessary memory initialization.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Parallel Seq Scan
Next
From: Stephen Frost
Date:
Subject: Re: Parallel Seq Scan