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

On 2013-01-24 12:30:02 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Backend A: does SET PERSISTENT foobar =..;
> > Backend B: does SET PERSISTENT foobar =..;
>
> > Now B overwrites the config change A has made as they are all stored in
> > the same file.
>
> Say what?  I thought the plan was one setting per file, so that we don't
> get involved in having to parse-and-edit the file contents.  What was
> all that argument about a new directory, if we're only using one file?

I initially thought that as well (and voted for it) but after reskimming
the thread and reading the patch that doesn't seem to be the case unless
its implemented in a way I don't understand:

+#define PG_AUTOCONF_DIR            "auto.conf.d"
+#define PG_AUTOCONF_FILENAME       "postgresql.auto.conf"

+   /* Frame auto conf name and auto conf sample temp file name */
+   snprintf(AutoConfFileName, sizeof(AutoConfFileName), "%s/%s/%s",
+                       ConfigFileDir,
+                       PG_AUTOCONF_DIR,
+                       PG_AUTOCONF_FILENAME);
+   snprintf(AutoConfTmpFileName, sizeof(AutoConfTmpFileName),"%s/%s/%s.%d",
+                       ConfigFileDir,
+                       PG_AUTOCONF_DIR,
+                       PG_AUTOCONF_FILENAME,
+                       (int) getpid());
+

I don't understand what the conf.d is all about either if only one file
is going to be used.

> If we are using just one file, then I agree a lock would be needed to
> synchronize updates.  But that seems to add a lot of complication
> elsewhere.

More people seem to have voted for the single file approach but I still
haven't understood why...

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services