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

From Michael Paquier
Subject Clean up hba.c of code freeing regexps
Date
Msg-id ZDdJ289Ky2qEj4h+@paquier.xyz
Whole thread Raw
Responses Re: Clean up hba.c of code freeing regexps  (Thomas Munro <thomas.munro@gmail.com>)
Re: Clean up hba.c of code freeing regexps  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Hi all,

With db4f21e in place, there is no need to worry about explicitely
freeing any regular expressions that may have been compiled when
loading HBA or ident files because MemoryContextDelete() would be
able to take care of that now that these are palloc'd (the definitions
in regcustom.h superseed the ones of regguts.h).

The logic in hba.c that scans all the HBA and ident lines to any
regexps can be simplified a lot.  Most of this code is new in 16~, so
I think that it is worth cleaning up this stuff now rather than wait
for 17 to open for business.  Still, this is optional, and I don't
mind waiting for 17 if the regexp/palloc business proves to be an
issue during beta.

FWIW, one would see leaks in the postmaster process with files like
that on repeated SIGHUPs before db4f21e:
$ cat $PGDATA/pg_hba.conf
local   "/^db\d{2,4}$"  all trust
local   "/^db\d{2,po}$"  all trust
local   "/^db\d{2,4}$"  all trust
$ cat $PGDATA/pg_ident.conf
foo "/^user\d{2,po}$"  bar
foo "/^uesr\d{2,4}$"  bar

With this configuration, there are no leaks on SIGHUPs after db4f21e
as MemoryContextDelete() does all the job.  Please see the attached.

Thoughts or opinions?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: Fix incorrect start up costs for WindowAgg paths (bug #17862)
Next
From: Melanie Plageman
Date:
Subject: Re: Wrong results from Parallel Hash Full Join