On Sat, Jan 10, 2015 at 2:27 AM, Bruce Momjian wrote:
> 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
> On Fri, Jan 9, 2015 at 9:23 PM, Tatsuo Ishii wrote:
>> This is because gen_db_file_maps() allocates memory even if n_maps == 0.
> Purely cosmetic: the initialization n_maps = 0 before the call of
> gen_db_file_maps is unnecessary ;)
Of course. n_maps is written by calling gen_db_file_maps() any
On Fri, Jan 9, 2015 at 11:34:24AM -0500, Tom Lane wrote:
> Tatsuo Ishii 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
Tatsuo Ishii 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.
On Fri, Jan 9, 2015 at 9:23 PM, Tatsuo Ishii wrote:
> This is because gen_db_file_maps() allocates memory even if n_maps == 0.
Purely cosmetic: the initialization n_maps = 0 before the call of
gen_db_file_maps is unnecessary ;)
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
According to Coverity, there's a memory leak bug in transfer_all_new_dbs().
mappings = gen_db_file_maps(old_db, new_db, &n_maps, old_pgdata,
new_pgdata);
if (n_maps)
{
