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
