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

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: pg_hba_lookup function to get all matching pg_hba.conf entries
Дата
Msg-id CAJrrPGdDWt-dx0uaPMDwOtoZeLyzZaabWr4hojrnyirkYp2Qgg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_hba_lookup function to get all matching pg_hba.conf entries  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Ответы Re: pg_hba_lookup function to get all matching pg_hba.conf entries  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Список pgsql-hackers
On Wed, Dec 30, 2015 at 1:07 AM, Shulgin, Oleksandr
<oleksandr.shulgin@zalando.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

Вложения

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

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Document brin_summarize_new_pages
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Some 9.5beta2 backend processes not terminating properly?