Re: Proposal for Allow postgresql.conf values to be changed via SQL

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com