Re: valgrind error in subscription code

From: Andres Freund <andres(at)anarazel(dot)de>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: valgrind error in subscription code
Date: 2017-04-22 19:16:51
Message-ID: 20170422191651.fufp7lczgovxpcer@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2017-04-22 21:08:18 +0200, Petr Jelinek wrote:
> Thanks, here is patch to fix that - I also removed the individual
> settings of everything to NULL/0/InvalidOid etc and just replaced it all
> with memset.

Cool.

> diff --git a/src/backend/replication/logical/relation.c b/src/backend/replication/logical/relation.c
> index 875a081..5bc54dd 100644
> --- a/src/backend/replication/logical/relation.c
> +++ b/src/backend/replication/logical/relation.c
> @@ -141,19 +141,10 @@ logicalrep_relmap_free_entry(LogicalRepRelMapEntry *entry)
> pfree(remoterel->attnames);
> pfree(remoterel->atttyps);
> }
> - remoterel->attnames = NULL;
> - remoterel->atttyps = NULL;
> -
> bms_free(remoterel->attkeys);
> - remoterel->attkeys = NULL;
>
> if (entry->attrmap)
> pfree(entry->attrmap);
> -

Btw, I think it's a good pattern to zero things like attrmap after
freeing. Based on a minute of looking it's unclear to me if
logicalrep_relmap_update() could be called again, if e.g. one of the
pallocs after the logicalrep_relmap_free_entry() errors out. I think
you essentially addressed that with the memset, so that's good.

- Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-04-22 19:38:43 Re: A note about debugging TAP failures
Previous Message Petr Jelinek 2017-04-22 19:08:18 Re: valgrind error in subscription code