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

On Monday, November 12, 2012 12:07 PM Greg Smith wrote:
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.

Yes, we should evaluate multiple options to do this and then choose the best among it.
I am ready to work on evaluating other ways to accomplish this feature.

Is the above opinion about only locking or even on a way to write the changed things in a file as mentioned in point-1
inmail chain upthread. 
(Point-1: > 1. While writing .auto file, it will always assume that .auto file contain
> all config parameters.
>   Now as this .auto file is of fixed format and fixed record size, it can
> directly write a given record to its particular position.)
What my thinking was that if we can decide that the format and size of each configuration is fixed, it can be directly
writtenwithout doing anything for it in memory. 


> 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.

As per my understanding,
a. during initdb, new conf directory can be created and also create .auto file in it.
b. use include_dir at end of postgresql.conf to include directory created in above step.
c. server start/sighup will take care of above include_dir


> 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.

Okay, what I will do for this is that I shall explain in next mail the way to do by navigating GUC's.

> 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.

Okay.

> 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.



With Regards,
Amit Kapila.