Patch for 9.1: initdb -C option
in [PgSql]
|
From: KaiGai Kohei on 14 Jul 2010 20:16 David, I'd like to volunteer reviewing your patch at first in this commit fest. We already had a few comments on the list before. I want to see your opinion for the suggestions prior to code reviews. Itagaki-san suggested: | > Enclosed is a patch to add a -C option to initdb to allow you to easily | > append configuration directives to the generated postgresql.conf file | Why don't you use just "echo 'options' >> $PGDATA/postgresql.conf" ? | Could you explain where the -C options is better than initdb + echo? Greg suggested: | We had a patch not quite make it for 9.0 that switched over the postgresql.conf | file to make it easy to scan a whole directory looking for configuration files: | http://archives.postgresql.org/message-id/9837222c0910240641p7d75e2a4u2cfa6c1b5e603d84(a)mail.gmail.com | | The idea there was to eventually reduce the amount of postgresql.conf hacking | that initdb and other tools have to do. Your patch would add more code into | a path that I'd like to see reduced significantly. | | That implementation would make something easy enough for your use case too | (below untested but show the general idea): | | $ for cluster in 1 2 3 4 5 6; | do initdb -D data$cluster | ( | cat <<EOF | port = 1234$cluster; | max_connections = 10; | shared_buffers=1M; | EOF | ) > data$cluster/conf.d/99clustersetup | done | | This would actually work just fine for what you're doing right now if you used | ">> data$cluster/postgresql.conf" for that next to last line there. | There would be duplicates, which I'm guessing is what you wanted to avoid with | this patch, but the later values set for the parameters added to the end would | win and be the active ones. Peter suggested: | > Enclosed is a patch to add a -C option to initdb to allow you to easily | > append configuration directives to the generated postgresql.conf file | > for use in programmatic generation. | I like this idea, but please use small -c for consistency with the | postgres program. It seems to me what Greg suggested is a recent trend. Additional configurations within separated files enables to install/uninstall third-party plugins easily from the perspective of packagers, rather than consolidated configuration. However, $PGDATA/postgresql.conf is created on initdb, so it does not belong to a certain package. I don't have certainty whether the recent trend is also suitable for us, or not. Thanks, (2010/03/29 14:04), David Christensen wrote: > Hackers, > > Enclosed is a patch to add a -C option to initdb to allow you to easily append configuration directives to the generated postgresql.conf file for use in programmatic generation. In my case, I'd been creating multiple db clusters with a script and would have specific overrides that I needed to make. This patch fell out of the desire to make this a little cleaner. Please review and comment. > > From the commit message: > > This is a simple mechanism to allow you to provide explicit overrides > to any GUC at initdb time. As a basic example, consider the case > where you are programmatically generating multiple db clusters in > order to test various configurations: > > $ for cluster in 1 2 3 4 5 6; > > do initdb -D data$cluster -C "port = 1234$cluster" -C 'max_connections = 10' -C shared_buffers=1M; > > done > > A possible future improvement would be to provide some basic > formatting corrections to allow specificications such as -C 'port > 1234', -C port=1234, and -C 'port = 1234' to all be ultimately output > as 'port = 1234' in the final output. This would be consistent with > postmaster's parsing. > > The -C flag was chosen to be a mnemonic for "config". > > Regards, > > David > -- > David Christensen > End Point Corporation > david(a)endpoint.com > -- KaiGai Kohei <kaigai(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 20 Jul 2010 18:00 Top posting. On purpose. :p This patch seems to be foundering in a sea of opinions. It seems that everybody wants to do *something* about this, but what? For one more opinion, my shop has chosen to never touch the default postgresql.conf file any more, beyond adding one line to the bottom of it which is an include directive, to bring in our overrides. What will make everyone happy here? -Kevin KaiGai Kohei <kaigai(a)ak.jp.nec.com> wrote: > (2010/03/29 14:04), David Christensen wrote: >> Enclosed is a patch to add a -C option to initdb to allow you to >> easily append configuration directives to the generated >> postgresql.conf file for use in programmatic generation. In my >> case, I'd been creating multiple db clusters with a script and >> would have specific overrides that I needed to make. This patch >> fell out of the desire to make this a little cleaner. >> Please review and comment. >> >> From the commit message: >> >> This is a simple mechanism to allow you to provide explicit >> overrides to any GUC at initdb time. As a basic example, >> consider the case where you are programmatically generating >> multiple db clusters in order to test various >> configurations: >> >> $ for cluster in 1 2 3 4 5 6; >> > do initdb -D data$cluster -C "port = 1234$cluster" \ >> > -C 'max_connections = 10' -C shared_buffers=1M; >> > done >> >> A possible future improvement would be to provide some basic >> formatting corrections to allow specificications such as -C >> 'port 1234', -C port=1234, and -C 'port = 1234' to all be >> ultimately output as 'port = 1234' in the final output. >> This would be consistent with postmaster's parsing. >> >> The -C flag was chosen to be a mnemonic for "config". > I'd like to volunteer reviewing your patch at first in this commit > fest. > > We already had a few comments on the list before. I want to see > your opinion for the suggestions prior to code reviews. > > Itagaki-san suggested: > | Why don't you use just "echo 'options' \ > | >>$PGDATA/postgresql.conf" ? > | Could you explain where the -C options is better than initdb + > | echo? > > Greg suggested: > | We had a patch not quite make it for 9.0 that switched over the > | postgresql.conf file to make it easy to scan a whole directory > | looking for configuration files: > | http://archives.postgresql.org/message-id/9837222c0910240641p7d75e2a4u2cfa6c1b5e603d84(a)mail.gmail.com > | > | The idea there was to eventually reduce the amount of > | postgresql.conf hacking that initdb and other tools have to do. > | Your patch would add more code into a path that I'd like to see > | reduced significantly. > | > | That implementation would make something easy enough for your > | use case too (below untested but show the general idea): > | > | $ for cluster in 1 2 3 4 5 6; > | do initdb -D data$cluster > | ( > | cat <<EOF > | port = 1234$cluster; > | max_connections = 10; > | shared_buffers=1M; > | EOF > | ) > data$cluster/conf.d/99clustersetup > | done > | > | This would actually work just fine for what you're doing right > | now if you used ">> data$cluster/postgresql.conf" for that next > | to last line there. There would be duplicates, which I'm > | guessing is what you wanted to avoid with this patch, but the > | later values set for the parameters added to the end would win > | and be the active ones. > > Peter suggested: > | I like this idea, but please use small -c for consistency with > | the postgres program. > > It seems to me what Greg suggested is a recent trend. Additional > configurations within separated files enables to install/uninstall > third-party plugins easily from the perspective of packagers, > rather than consolidated configuration. > > However, $PGDATA/postgresql.conf is created on initdb, so it does > not belong to a certain package. I don't have certainty whether > the recent trend is also suitable for us, or not. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Christensen on 20 Jul 2010 18:16 On Jul 20, 2010, at 5:00 PM, Kevin Grittner wrote: > Top posting. On purpose. :p > > This patch seems to be foundering in a sea of opinions. It seems > that everybody wants to do *something* about this, but what? > > For one more opinion, my shop has chosen to never touch the default > postgresql.conf file any more, beyond adding one line to the bottom > of it which is an include directive, to bring in our overrides. > > What will make everyone happy here? So you'll now issue: $ initdb ... -C 'include localconfig.conf' ? :-) Regards, David -- David Christensen End Point Corporation david(a)endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 20 Jul 2010 18:33 David Christensen <david(a)endpoint.com> wrote: > On Jul 20, 2010, at 5:00 PM, Kevin Grittner wrote: >> my shop has chosen to never touch the default postgresql.conf >> file any more, beyond adding one line to the bottom of it which >> is an include directive, to bring in our overrides. > So you'll now issue: > > $ initdb ... -C 'include localconfig.conf' ? :-) Yeah, that would cover us. I'm wondering if it is flexible enough to serve everyone else so well. I hesitate to suggest it, but perhaps it would, in combination with the include directive supporting a directory name to mean all files in the directory? Or maybe if it supported wildcards? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 20 Jul 2010 20:15 (2010/07/21 7:33), Kevin Grittner wrote: > David Christensen<david(a)endpoint.com> wrote: >> On Jul 20, 2010, at 5:00 PM, Kevin Grittner wrote: > >>> my shop has chosen to never touch the default postgresql.conf >>> file any more, beyond adding one line to the bottom of it which >>> is an include directive, to bring in our overrides. > >> So you'll now issue: >> >> $ initdb ... -C 'include localconfig.conf' ? :-) > > Yeah, that would cover us. I'm wondering if it is flexible enough > to serve everyone else so well. I hesitate to suggest it, but > perhaps it would, in combination with the include directive > supporting a directory name to mean all files in the directory? Or > maybe if it supported wildcards? > I reminded that David introduced the following example as a usage of this feature. $ for cluster in 1 2 3 4 5 6; do initdb -D data$cluster -C "port = 1234$cluster" \ -C 'max_connections = 10' \ -C shared_buffers=1M; done In this case, it tries to set up six database clusters with constant max_connections and shared_buffers, but individual port numbers for each database clusters. Even if we support include directive here, it may not help to describe the postgresql.conf with a smart way. Then, how about the Itagaki-san's suggestion? Itagaki-san suggested: | > Enclosed is a patch to add a -C option to initdb to allow you to easily | > append configuration directives to the generated postgresql.conf file | Why don't you use just "echo 'options' >> $PGDATA/postgresql.conf" ? | Could you explain where the -C options is better than initdb + echo? As long as you don't need any special configuration during the initial setting up launched by initdb, indeed, it seems to me we can edit the postgresql.conf later. Thanks, -- KaiGai Kohei <kaigai(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 Prev: Per-column collation, proof of concept Next: [HACKERS] CommitFest 2010-07 now in progress |