Re: pg_hba_lookup function to get all matching pg_hba.conf entries

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_hba_lookup function to get all matching pg_hba.conf entries
Date: 2015-12-30 03:31:12
Message-ID: CAJrrPGdDWt-dx0uaPMDwOtoZeLyzZaabWr4hojrnyirkYp2Qgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 30, 2015 at 1:07 AM, Shulgin, Oleksandr
<oleksandr(dot)shulgin(at)zalando(dot)de> wrote:
>
> This is close enough, but what I actually mean by "a callback" is more or
> less like the attached version.

Thanks for the changes.

> While at it, I've also added some trivial code to preserve keyword quoting
> in database and user fields, as well as added netmask output parameter; also
> documentation is extended a little.

Thanks for the documentation changes and regarding the quoting, in any system
catalog table, the quoted objects are represented without quotes as below.

postgres=> select datname from pg_database;
datname
---------------
postgres
template1
template0
test_user2_db
TEST_USER1_DB
test_user2_dB
(6 rows)

Adding quotes to pg_hba_lookup function makes it different from others.
The issues regarding the same is already discussed in [1].

select a.database[1], b.datname from pg_hba_lookup('postgres','kommih','::1')
as a, pg_database as b where a.database[1]
= b.datname;

The queries like above are not possible with quoted output. It is very
rare that the
pg_hba_lookup function used in join operations, but still it is better
to provide
data without quotes. so I reverted these changes in the attached latest patch.

> The biggest question for me is the proper handling of memory contexts for
> HBA and ident files data. I think it makes sense to release them explicitly
> because with the current state of affairs, we have dangling pointers in
> parsed_{hba,ident}_{context,lines} after release of PostmasterContext. The
> detailed comment in postgres.c around
> MemoryContextDelete(PostmasterContext); suggests that it's not easy already
> to keep track of the all things that might be affected by this cleanup step:
>
> /*
> * If the PostmasterContext is still around, recycle the space; we don't
> * need it anymore after InitPostgres completes. Note this does not trash
> * *MyProcPort, because ConnCreate() allocated that space with malloc()
> * ... else we'd need to copy the Port data first. Also, subsidiary data
> * such as the username isn't lost either; see ProcessStartupPacket().
> */
>
> Not sure if we need any advanced machinery here like some sort of cleanup
> hooks list? For now I've added discard_{hba,ident}() functions and call
> them explicitly where appropriate.

The added functions properly frees the hba and ident contexts once its use is
finished. I removed the discard function calls in PerformAuthentication function
in EXEC_BACKEND mode, as these are called once the PerformAuthenication
function finishes.

The discard hba and ident context patch is separated from
pg_hba_lookup patch for
easier understanding. The pg_hba_lookup patch needs to be applied on top of
discard_hba_and_ident_cxt patch.

[1] http://www.postgresql.org/message-id/CAFj8pRARzDScocMK30gyYdOgiwuTUcZ7EvE-bBg+wV2Wg5EQRQ@mail.gmail.com

Regards,
Hari Babu
Fujitsu Australia

Attachment Content-Type Size
pg_hba_lookup_poc_v11.patch application/octet-stream 24.3 KB
discard_hba_and_ident_cxt.patch application/octet-stream 4.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-12-30 03:32:58 Re: Some 9.5beta2 backend processes not terminating properly?
Previous Message Tatsuo Ishii 2015-12-30 02:55:03 Re: [COMMITTERS] pgsql: Document brin_summarize_new_pages