Re: Clean up hba.c of code freeing regexps

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Clean up hba.c of code freeing regexps
Date: 2023-04-13 01:24:00
Message-ID: ZDdZsIa+jfH6o/eN@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2023-04-13 01:29:38 Re: Bufmgr possible overflow
Previous Message Justin Pryzby 2023-04-13 00:53:53 Re: Add LZ4 compression in pg_dump