Configuration include directory
От | Greg Smith |
---|---|
Тема | Configuration include directory |
Дата | |
Msg-id | 4EC341E1.1060908@2ndQuadrant.com обсуждение исходный текст |
Ответы |
Re: Configuration include directory
(Greg Jaskiewicz <gj@pointblue.com.pl>)
Re: Configuration include directory (Noah Misch <noah@leadboat.com>) Re: Configuration include directory (Marti Raudsepp <marti@juffo.org>) Re: Configuration include directory (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Two years ago Magnus submitted a patch to parse all the configuration files in a directory. After some discussion I tried to summarize what I thought the most popular ideas were for moving that forward: http://archives.postgresql.org/pgsql-hackers/2009-10/msg01452.php http://archives.postgresql.org/pgsql-hackers/2009-10/msg01631.php And I've now cleared the bit rot and updated that patch to do what was discussed. Main feature set: -Called by specifying "includedir <directory>". No changes to the shipped postgresql.conf yet. -Takes an input directory name -If it's not an absolute path, considers that relative to the -D option (if specified) or PGDATA, the same logic used to locate the postgresql.conf (unless a full path to it is used) -Considers all names in that directory that end with *.conf [Discussion concluded more flexibility here would be of limited value relative to how it complicates the implementation] -Loops over the files found in sorted order by name The idea here is that it will be easier to write tools that customize the database configuration if they can just write a new file out, rather than needing to parse the whole configuration file first. This would allow Apache style configuration directories. My end goal here is to see all of the work initdb does pushed into a new file included by this scheme. People could then expect a functionally empty postgresql.conf except for an includedir, and the customization would go into 00initdb. Getting some agreement on that is not necessary for this feature to go in though; one step at a time. Here's an example showing this working, including rejection of a spurious editor backup file in the directory: $ cat $PGDATA/postgresql.conf | grep ^work_mem $ tail -n 1 $PGDATA/postgresql.conf includedir='conf.d' $ ls $PGDATA/conf.d 00config.conf 00config.conf~ $ cat $PGDATA/conf.d/00config.conf work_mem=4MB $ cat $PGDATA/conf.d/00config.conf~ work_mem=2MB $ psql -c "select name,setting,sourcefile,sourceline from pg_settings where name='work_mem'" name | setting | sourcefile | sourceline ----------+---------+-------------------------------------------------------+------------ work_mem | 4096 | /home/gsmith/pgwork/data/confdir/conf.d/00config.conf | 1 No docs in here yet. There's one ugly bit of code here I was hoping (but failed) to avoid. Right now the server doesn't actually save the configuration directory anywhere. Once you leave the initial read in SelectConfigFiles, that information is gone, and you only have the configfile. I decided to make that configdir into a global value. Seemed easier than trying to pass it around, given how many SIGHUP paths could lead to this new code. I can see some potential confusion here in one case. Let's say someone specifies a full path to their postgresql.conf file. They might assume that the includedir was relative to the directory that file is in. Let's say configfile is /etc/sysconfig/pgsql/postgresql.conf ; a user might think that "includedir conf.d" from there would reference /etc/sysconfig/pgsql/conf.d instead of the $PGDATA/conf.d you actually get. Wavering on how to handle that is one reason I didn't try documenting this yet, the decision I made here may not actually be the right one. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
Вложения
В списке pgsql-hackers по дате отправления: