Re: Small memory fixes for pg_createsubcriber
От | Andres Freund |
---|---|
Тема | Re: Small memory fixes for pg_createsubcriber |
Дата | |
Msg-id | obqvpv4yx57lbnfiqvy4pmnfi2l5wn6xzoq2ftytxa426pa226@2sc46frt5xtb обсуждение исходный текст |
Ответ на | Re: Small memory fixes for pg_createsubcriber ("Euler Taveira" <euler@eulerto.com>) |
Ответы |
Re: Small memory fixes for pg_createsubcriber
|
Список | 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
В списке pgsql-hackers по дате отправления: