Re: Dynamic configuration via LDAP in postmaster - Mailing list pgsql-hackers

From Vasily Soshnikov
Subject Re: Dynamic configuration via LDAP in postmaster
Date
Msg-id CAJb1v+kFOSwYRuiTB9=8YFG4e7=1KrMkAPOk1NQWwEJPOmyxog@mail.gmail.com
Whole thread
In response to Re: Dynamic configuration via LDAP in postmaster  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
Thank you for the advice, nowadays we(company where I work) use such scheme but that scheme is not always useful at the stage of development of the back-end infrastructure. Also we have found a better solution : have ldap for dynamic configuraion out of the box.

So question is following: if you got such task, where do you put ldap functionality inside postgres daemon?

PS I have read the basics of ideology Posgresql and I know why you guys make main server tiny in functionality and this is great, but we would like to have more complex solution.
This feature may be useful not only for me and my company.  


On 3 December 2013 20:54, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 12/03/2013 05:44 PM, Vasily Soshnikov wrote:
I need advise about where is best place for adding such features.

Currently I found that 'postmaster' have event loop(including handling
SIGHUP) inside PostgressMain(postgress.c)  for realoding configuration
file, based on my investigation my plan is handling ldap events just before
SIGHUP.

PS I guess tomorrow I will start implement this feature inside
'postmaster', but before I start I wish to know expert opinion about where
are most good place for dispatching of incomming messages(about
configuration has changed etc) from the ldap.

postmaster is kept very small on purpose, because if that process dies, it will take the whole server down with it. I'd suggest writing a custom background worker that talks with the ldap server. It can then write the changes to the configuration files, and send SIGHUP to reload.

- Heikki



--

Regard,

Soshnikov Vasily mailto:dedok.mad@gmail.com

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Next
From: Magnus Hagander
Date:
Subject: Re: pgsql: Fix a couple of bugs in MultiXactId freezing