Horton

Re: Small memory fixes for pg_createsubcriber

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Euler Taveira <euler@eulerto.com>
Cc: "ranier.vf@gmail.com" <ranier.vf@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-02-12T14:34:24Z
Lists: pgsql-hackers 
Hi,

On 2025-02-11 13:32:32 -0300, Euler Taveira wrote:
> On Mon, Feb 10, 2025, at 1:31 PM, Ranier Vilela wrote:
> > Coverity has some reports about pg_createsubcriber.
> > 
> > CID 1591322: (#1 of 1): Resource leak (RESOURCE_LEAK)
> > 10. leaked_storage: Variable dbname going out of scope leaks the storage it points to.
> > Additionally there are several calls that are out of the ordinary, according to the Postgres API.
> > 
> > According to the documentation:
> > libpq-exec <https://www.postgresql.org/docs/current/libpq-exec.html>
> > 
> > 
> > The correct function to free memory when using PQescapeLiteral and PQescapeIdentifier would be PQfreemem.
> > 
> 
> Hi,
> 
> From src/common/fe_memutils.c:
> 
> void
> pg_free(void *ptr)
> {
>     free(ptr);
> }
> 
> From src/interfaces/libpq/fe-exec.c:
> 
> void
> PQfreemem(void *ptr)
> {
>     free(ptr);
> }
> 
> There is no bug. They are the same behind the scenes. I'm fine changing it. It
> is a new code and it wouldn't cause a lot of pain to backpatch patches in the
> future.

That *is* a bug. On windows the allocator that a shared library (i.e. libpq)
uses, may *not* be the same as the one that an executable
(i.e. pg_createsubscriber).  It's not correct to free memory allocated in a
shared library just with free, it has to go through the library's free.

Greetings,

Andres Freund

Commits

  1. pg_upgrade: Fix inconsistency in memory freeing

  2. pg_amcheck: Fix inconsistency in memory freeing

  3. Fix some inconsistencies with memory freeing in pg_createsubscriber

  4. Drop pre-existing subscriptions from the converted subscriber.