Re: Small memory fixes for pg_createsubcriber

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "ranier(dot)vf(at)gmail(dot)com" <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Small memory fixes for pg_createsubcriber
Date: 2025-02-11 16:32:32
Message-ID: 68d6d810-4ef1-4f62-b47f-89b21501249b@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

@@ -1130,6 +1130,7 @@ check_and_drop_existing_subscriptions(PGconn *conn,

PQclear(res);
destroyPQExpBuffer(query);
+ PQfreemem(dbname);
}

Even if the pg_createsubscriber aims to run in a small amount of time, hence,
it is fine to leak memory, the initial commit cleaned up all variables but a
subsequent commit 4867f8a555c apparently didn't. Although it is just a low
impact improvement, it is better to be strict and shut up SASTs.

--
Euler Taveira
EDB https://www.enterprisedb.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-02-11 16:49:59 Re: pg_stat_statements and "IN" conditions
Previous Message Andres Freund 2025-02-11 16:31:46 Re: Eagerly scan all-visible pages to amortize aggressive vacuum