Re: Clean up hba.c of code freeing regexps - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Clean up hba.c of code freeing regexps
Date
Msg-id ZDdZsIa+jfH6o/eN@paquier.xyz
Whole thread Raw
In response to Re: Clean up hba.c of code freeing regexps  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Clean up hba.c of code freeing regexps  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Apr 13, 2023 at 12:53:51PM +1200, Thomas Munro wrote:
> Up to the RMT of course, but it sounds a bit like (1) you potentially
> had an open item already until last week (new code in 16 that could
> leak regexes),

Well, not really..  Note that HEAD does not leak regexes, because
changes like 02d3448 have made sure that all these are explicitely
freed when a file is parsed and where there is no need to switch to
the new one because errors were found on the way.  In short, one can
just take the previous conf files I pasted and there will be no leaks
on HEAD in the context of the postmaster, even before bea3d7e.  Sure,
there could be issues if one changed the shape of the code, but all
the existing compiled regexes were covered (this stuff already exists
in ~15 for the regexps of the user name in ident lines).

> and (2) I missed this when looking for manual memory
> management code that could be nuked, probably because it's hiding
> behind a few layers of functions call, but there are clearly comments
> that are now wrong.  So there are two different ways for a commitfest
> lawyer to argue this should be tidied up for 16.

Yes, the comments are incorrect anyway.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Add LZ4 compression in pg_dump
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Bufmgr possible overflow