On 10 Apr 2024, at 20:31, Ranier Vilela <ranier.vf@gmail.com> wrote:Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson <daniel@yesql.se> escreveu:> On 2 Apr 2024, at 20:13, Ranier Vilela <ranier.vf@gmail.com> wrote: > Fix by freeing the pointer, like pclose_check (src/common/exec.c) similar case. Off the cuff, seems reasonable when loglevel is LOG.Per Coverity.Another case of resource leak, when loglevel is LOG.In the function shell_archive_file (src/backend/archive/shell_archive.c)The pointer *xlogarchcmd* is not freed.Thanks, I'll have a look. I've left this for post-freeze on purpose to notcause unnecessary rebasing. Will take a look over the next few days unlessbeaten to it.
On 10 Apr 2024, at 20:31, Ranier Vilela <ranier.vf@gmail.com> wrote:Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson <daniel@yesql.se> escreveu:> On 2 Apr 2024, at 20:13, Ranier Vilela <ranier.vf@gmail.com> wrote: > Fix by freeing the pointer, like pclose_check (src/common/exec.c) similar case. Off the cuff, seems reasonable when loglevel is LOG.Per Coverity.Another case of resource leak, when loglevel is LOG.In the function shell_archive_file (src/backend/archive/shell_archive.c)The pointer *xlogarchcmd* is not freed.
> On 2 Apr 2024, at 20:13, Ranier Vilela <ranier.vf@gmail.com> wrote: > Fix by freeing the pointer, like pclose_check (src/common/exec.c) similar case. Off the cuff, seems reasonable when loglevel is LOG.
pgsql-hackers by date:
Соглашаюсь с условиями обработки персональных данных