On 2013-01-24 12:30:02 -0500, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
