On Mon, Dec 28, 2015 at 9:09 PM, Shulgin, Oleksandr <oleksandr.shul...@zalando.de> wrote: > On Thu, Dec 24, 2015 at 5:16 AM, Haribabu Kommi <kommi.harib...@gmail.com> > wrote: >> >> On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: >> >> 1. Have you considered re-loading the HBA file upon call to this >> >> function >> >> in a local context instead of keeping it in the backends memory? >> > >> > Aside from the security questions, please consider that this feature >> > should >> > work similarly to the current implementation of the pg_file_settings >> > view, >> > namely it tells you about what is *currently* in the on-disk files, not >> > necessarily what is the active setting in the postmaster's memory. >> > A backend could not be entirely sure about the postmaster's state >> > anyway; >> > and even if it could be, one of the major applications for features like >> > this is testing manual changes to the files before you SIGHUP the >> > postmaster. So re-reading the files on each usage is a Good Thing, IMO, >> > even if it sounds inefficient. >> > >> >> 2. I also wonder why JSONB arrays for database/user instead of TEXT[]? >> > >> > Yes, that seems rather random to me too. >> >> Here I attached updated patch with the following changes, >> - Local loading of HBA file to show the authentication data >> - Changed database and user types are text[] > > > Still this requires a revert of the memory context handling commit for > load_hba() and load_ident(). I think you can get around the problem by > changing these functions to work with CurrentMemoryContext and set it > explicitly to the newly allocated PostmasterContext in > PerformAuthentication(). In your function you could then create a temporary > context to be discarded before leaving the function.
Thanks for the review. I didn't understand your point clearly. In the attached patch, load_hba uses PostmasterContext if it is present, otherwise CurretMemoryContext. PostmasterContext is present only in the backend start phase. > I still think you should not try to re-implement check_hba(), but extend > this function with means to report line skip reasons as per your > requirements. Having an optional callback function might be a good fit (a > possible use case is logging the reasons line by line). check_hba function is enhanced to fill the hba line details with reason for mismatch. In check_hba function whenever a mismatch is found, the fill_hbaline function is called to frame the tuple and inserted into tuple store. Regards, Hari Babu Fujitsu Australia
pg_hba_lookup_poc_v9.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
