Re: Proposal for Allow postgresql.conf values to be changed via SQL - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date
Msg-id 50A09943.5090809@2ndQuadrant.com
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit kapila <amit.kapila@huawei.com>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit kapila <amit.kapila@huawei.com>)
List pgsql-hackers
On 11/9/12 11:59 PM, Amit kapila wrote:

> Please let me know if there are any objections or problems in above method of implementation,
> else I can go ahead to prepare the patch for the coming CF.

It may be the case that the locking scheme Robert described is the best 
approach here.  It seems kind of heavy to me though.  I suspect that 
some more thinking about it might come up with something better.

Regardless, exactly how to prevent two concurrent processes from writing 
the same file feels like the last step in the small roadmap for what 
this feature needs.  If you wanted to work on it more, I'd suggest 
breaking it into chunks in this order:

1) Change to add scanning a .conf directory in the default configuration 
using include-dir.  This is a quick fix.  I predict most of the 
headaches around it will end up being for packagers rather than the core 
code to deal with.

You could submit this as a small thing to be evaluated on its own.  How 
it's done is going to be controversial.  Might as well get that fighting 
focused against a sample implementation as soon as possible.

2) Get familiar with navigating the GUC data and figuring out what, 
exactly, needs to be written out.  This should include something that 
navigates like things appear after a RESET, ignoring per-user or 
per-session changes when figuring out what goes there.  It seems 
inevitable that some amount of validating against the source 
information--what pg_settings labels source, sourcefile, and sourceline 
will be needed.  An example is the suggestion Magnus made for confirming 
that the include-dir is still active before writing something there.

3) Add the function to write a new file out.  Work out some test cases 
for that to confirm the logic and error checking in the previous step 
all works.

I'd next submit what you've got for (2) and (3) to review at this point, 
before complicating things further with the locking parts.

4) Make the file write atomic and able to work when multiple users try 
it at once.  You have to reach here successfully before the trivial 
around file locking comes into play.  I wouldn't even bother aiming for 
that part in a first patch.  It's obviously a solvable problem in a 
number of ways.  You need a rock solid way to figure out what to write 
there before that solution is useful though.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Enabling Checksums
Next
From: Heikki Linnakangas
Date:
Subject: Re: Inadequate thought about buffer locking during hot standby replay