Re: Clean up hba.c of code freeing regexps

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Clean up hba.c of code freeing regexps
Дата
Msg-id ZDdZsIa+jfH6o/eN@paquier.xyz
обсуждение исходный текст
Ответ на Re: Clean up hba.c of code freeing regexps  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Clean up hba.c of code freeing regexps  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Add LZ4 compression in pg_dump
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Bufmgr possible overflow