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