Re: [HACKERS] Adding a --quiet option to initdb
Jim C. Nasby wrote: On Thu, Jan 26, 2006 at 11:36:15AM +0100, Peter Eisentraut wrote: James William Pye wrote: Why should initdb give it [processing information] to the user if the user didn't request it in the first place? Because it shows important information that we want the user to see. If you're serious about the important information that we want the user to see, then you need to really think about what's important (see argument below). Otherwise, the output becomes a text-blurb that nobody reads. Plus it can be a fairly long-running process on slower machines, so providing feedback to the user is good. Good point, and well covered if a --verbose option is introduced. What is important information? What makes the user really see it? This is how I perceive the output from initdb: - The output lists settings for locale, encoding and buffer usage. Why are these specific settings be of special interest? Anyone with an interest in them knows where to find them anyway. This information is not important. - It lists (the successful creation of ) the internal directory structure of the data directory. This information is not important. - Some output is purely educational and thus belongs in the manual, not in a command output (This user must also own the server process, You can now start the database...). This information is not important. - Lot's of info is printed about successful creation of configuration files, template databases, conversions, information schema, system views, that pg_authid and dependencies has been initialized, database copying, etc. This information is not important. I still think it's much better to have complete silence unless there are warnings and/or errors. That makes them much easier to spot. Right now I get a WARNING: enabling trust authentication for local connections. Now this information *is* important. Unfortunately it's mixed in with all the rest unless I use a special redirect of stdout. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Adding a --quiet option to initdb
Thomas Hallgren [EMAIL PROTECTED] writes: This is how I perceive the output from initdb: - The output lists settings for locale, encoding and buffer usage. Why are these specific settings be of special interest? Anyone with an interest in them knows where to find them anyway. This information is not important. - It lists (the successful creation of ) the internal directory structure of the data directory. This information is not important. - Some output is purely educational and thus belongs in the manual, not in a command output (This user must also own the server process, You can now start the database...). This information is not important. - Lot's of info is printed about successful creation of configuration files, template databases, conversions, information schema, system views, that pg_authid and dependencies has been initialized, database copying, etc. This information is not important. I still think it's much better to have complete silence unless there are warnings and/or errors. That makes them much easier to spot. Right now I get a WARNING: enabling trust authentication for local connections. Now this information *is* important. Unfortunately it's mixed in with all the rest unless I use a special redirect of stdout. To apply your own argument, why is that important? Anyone with an interest in the authentication settings knows where to find them anyway. While we can probably all agree that it's not very interesting to mention every single directory that initdb creates, I find it fairly hard to buy an argument that some of the non-progress messages are important and the others are not. Every one of them got put in because someone thought it important. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Adding a --quiet option to initdb
Tom Lane wrote: I get a WARNING: enabling trust authentication for local connections. Now this information *is* important. Unfortunately it's mixed in with all the rest unless I use a special redirect of stdout. To apply your own argument, why is that important? Anyone with an interest in the authentication settings knows where to find them anyway. I see your point, and sure, this is just the result of PostgreSQL default behavior so the warning is unnecessary. It's all in the admin guide anyway. If the default behavior really calls for a warning, then the default behavior should change. My original line of though was that the warning was important since it is about a possible security vulnerability (it's printed on stderr rather than stdout where all the rest ends up so I'm not the only one making the distinction). While we can probably all agree that it's not very interesting to mention every single directory that initdb creates, I find it fairly hard to buy an argument that some of the non-progress messages are important and the others are not. Every one of them got put in because someone thought it important. I agree. The above warning is not an indication that something is wrong and it should be removed too. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Adding a --quiet option to initdb
Alvaro Herrera [EMAIL PROTECTED] writes: This warning was added because of security considerations AFAIR. If the intent is to make initdb super-quiet, we still have to have security in mind. So if you want it to not say anything by default, instead of throwing a warning it should throw an error and refuse to continue; unless a default password is specified or a --silently-enable-trust-auth switch is passed, in either of which cases it can silently continue. There is 0 chance that we will design initdb to fail by default. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Adding a --quiet option to initdb
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: This warning was added because of security considerations AFAIR. If the intent is to make initdb super-quiet, we still have to have security in mind. So if you want it to not say anything by default, instead of throwing a warning it should throw an error and refuse to continue; unless a default password is specified or a --silently-enable-trust-auth switch is passed, in either of which cases it can silently continue. There is 0 chance that we will design initdb to fail by default. I disagree with the goal that it should be super-quiet anyway, so I don't care anyway (and I also have scripts that work on the assumption that it works by default.) -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J Linux transformó mi computadora, de una `máquina para hacer cosas', en un aparato realmente entretenido, sobre el cual cada día aprendo algo nuevo (Jaime Salinas) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Adding a --quiet option to initdb
I wrote: While we can probably all agree that it's not very interesting to mention every single directory that initdb creates, I find it ... I took a quick look at the source and see that it would be trivial to reduce the current output from creating directory /home/postgres/v82/data ... ok creating directory /home/postgres/v82/data/global ... ok creating directory /home/postgres/v82/data/pg_xlog ... ok creating directory /home/postgres/v82/data/pg_xlog/archive_status ... ok creating directory /home/postgres/v82/data/pg_clog ... ok creating directory /home/postgres/v82/data/pg_subtrans ... ok creating directory /home/postgres/v82/data/pg_twophase ... ok creating directory /home/postgres/v82/data/pg_multixact/members ... ok creating directory /home/postgres/v82/data/pg_multixact/offsets ... ok creating directory /home/postgres/v82/data/base ... ok creating directory /home/postgres/v82/data/base/1 ... ok creating directory /home/postgres/v82/data/pg_tblspc ... ok selecting default max_connections ... 100 ... to creating directory /home/postgres/v82/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 ... which would go a long way to cutting down the perception of useless chatter. I think the per-subdirectory messages were put in at a time when we only created one or two such, but that was a long time ago. It doesn't take long to make a directory, so the messages aren't very useful as progress reports, and if the first creation succeeds then it's highly unlikely the rest will fail. (Of course, if one does fail we'll report its name at that point.) Barring objections I'll make this change, regardless of whether we later decide that all the progress messages ought to be dependent on a --verbose or --quiet flag. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Adding a --quiet option to initdb
to creating directory /home/postgres/v82/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 ... Less is more :) I like it. Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Adding a --quiet option to initdb
On Thu, Jan 26, 2006 at 11:36:15AM +0100, Peter Eisentraut wrote: James William Pye wrote: Why should initdb give it [processing information] to the user if the user didn't request it in the first place? Because it shows important information that we want the user to see. Plus it can be a fairly long-running process on slower machines, so providing feedback to the user is good. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Adding a --quiet option to initdb
Jim C. Nasby wrote: On Thu, Jan 26, 2006 at 11:36:15AM +0100, Peter Eisentraut wrote: James William Pye wrote: Why should initdb give it [processing information] to the user if the user didn't request it in the first place? Because it shows important information that we want the user to see. Plus it can be a fairly long-running process on slower machines, so providing feedback to the user is good. Moreover, we should not change behaviour just on aesthetic grounds. For example, if initdb were suddenly to become quiet by default, we would need to add some version-specific processing to the buildfarm. As for a --quiet option, I just don't see why it is needed when /dev/null works perfectly well. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Adding a --quiet option to initdb
Hi,
Attached is a patch which adds --quiet and --q option to initdb. I
personally needed this option while writing a document and taking
screenshot :) It only shows the error and warning messages, as well as
the last lines.
I've updated the docs. Regression tests pass.
This is my first patch to PostgreSQL source, so please guide me if I
have done something wrong.
Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Index: doc/src/sgml/ref/initdb.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/initdb.sgml,v
retrieving revision 1.35
diff -c -r1.35 initdb.sgml
*** doc/src/sgml/ref/initdb.sgml 21 Jun 2005 04:02:31 - 1.35
--- doc/src/sgml/ref/initdb.sgml 25 Jan 2006 13:47:19 -
***
*** 235,240
--- 235,252
/listitem
/varlistentry
+ variablelist
+ varlistentry
+ termoption--q/option/term
+ termoption--quiet/option/term
+ listitem
+para
+ Supresses the messages generated by commandinitdb/command. Only warning
+ and error messages are displayed.
+/para
+ /listitem
+ /varlistentry
+
varlistentry
termoption-L replaceable class=parameterdirectory/replaceable/option/term
listitem
Index: src/bin/initdb/initdb.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving revision 1.106
diff -c -r1.106 initdb.c
*** src/bin/initdb/initdb.c 5 Jan 2006 10:07:46 - 1.106
--- src/bin/initdb/initdb.c 25 Jan 2006 13:47:36 -
***
*** 95,100
--- 95,101
static bool debug = false;
static bool noclean = false;
static bool show_setting = false;
+ static bool quiet;
/* internal vars */
***
*** 1120,1128
test_max_fsm,
ok_buffers = 0;
!
! printf(_(selecting default max_connections ... ));
! fflush(stdout);
for (i = 0; i connslen; i++)
{
--- 1121,1131
test_max_fsm,
ok_buffers = 0;
! if (!quiet)
! {
! printf(_(selecting default max_connections ... ));
! fflush(stdout);
! }
for (i = 0; i connslen; i++)
{
***
*** 1150,1159
i = connslen - 1;
n_connections = trial_conns[i];
! printf(%d\n, n_connections);
! printf(_(selecting default shared_buffers/max_fsm_pages ... ));
! fflush(stdout);
for (i = 0; i bufslen; i++)
{
--- 1153,1168
i = connslen - 1;
n_connections = trial_conns[i];
! if (!quiet)
! {
! printf(%d\n, n_connections);
! }
! if (!quiet)
! {
! printf(_(selecting default shared_buffers/max_fsm_pages ... ));
! fflush(stdout);
! }
for (i = 0; i bufslen; i++)
{
***
*** 1181,1187
n_buffers = test_buffs;
n_fsm_pages = FSM_FOR_BUFS(n_buffers);
! printf(%d/%d\n, n_buffers, n_fsm_pages);
}
/*
--- 1190,1199
n_buffers = test_buffs;
n_fsm_pages = FSM_FOR_BUFS(n_buffers);
! if (!quiet)
! {
! printf(%d/%d\n, n_buffers, n_fsm_pages);
! }
}
/*
***
*** 1194,1202
char repltok[100];
char path[MAXPGPATH];
! fputs(_(creating configuration files ... ), stdout);
! fflush(stdout);
!
/* postgresql.conf */
conflines = readfile(conf_file);
--- 1206,1216
char repltok[100];
char path[MAXPGPATH];
! if (!quiet)
! {
! fputs(_(creating configuration files ... ), stdout);
! fflush(stdout);
! }
/* postgresql.conf */
conflines = readfile(conf_file);
***
*** 1350,1359
char **bki_lines;
char headerline[MAXPGPATH];
! printf(_(creating template1 database in %s/base/1 ... ), pg_data);
! fflush(stdout);
! if (debug)
talkargs = -d 5;
bki_lines = readfile(bki_file);
--- 1364,1376
char **bki_lines;
char headerline[MAXPGPATH];
! if (!quiet)
! {
! printf(_(creating template1 database in %s/base/1 ... ), pg_data);
! fflush(stdout);
! }
! if (debug)
talkargs = -d 5;
bki_lines = readfile(bki_file);
***
*** 1444,1451
NULL
};
! fputs(_(initializing pg_authid ... ), stdout);
! fflush(stdout);
snprintf(cmd, sizeof(cmd),
\%s\ %s template1 %s,
--- 1461,1471
NULL
};
! if (!quiet)
! {
! fputs(_(initializing pg_authid ... ), stdout);
! fflush(stdout);
! }
snprintf(cmd, sizeof(cmd),
\%s\ %s template1 %s,
***
*** 1572,1579
NULL
};
! fputs(_(enabling unlimited row size for system tables ... ), stdout);
! fflush(stdout);
snprintf(cmd, sizeof(cmd),
\%s\ %s template1 %s,
--- 1592,1602
NULL
};
! if (!quiet)
! {
! fputs(_(enabling unlimited row size
Re: [HACKERS] Adding a --quiet option to initdb
Devrim GUNDUZ [EMAIL PROTECTED] writes: Attached is a patch which adds --quiet and --q option to initdb. Why is this a good idea? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Adding a --quiet option to initdb
Hi, On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote: Devrim GUNDUZ [EMAIL PROTECTED] writes: Attached is a patch which adds --quiet and --q option to initdb. Why is this a good idea? I was playing with 8.2 RPM init script and thought that instead of directing the output to /dev/null, it would be better to use a command line option for that. Also, we are designing a new installer project and --quiet might help us. I would rise this idea in -hackers before providing a patch, but since this is my first patch, I thought it would be a good exercise for me. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Adding a --quiet option to initdb
Devrim GUNDUZ wrote: Hi, On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote: Devrim GUNDUZ [EMAIL PROTECTED] writes: Attached is a patch which adds --quiet and --q option to initdb. Why is this a good idea? I was playing with 8.2 RPM init script and thought that instead of directing the output to /dev/null, it would be better to use a command line option for that. Also, we are designing a new installer project and --quiet might help us. I would rise this idea in -hackers before providing a patch, but since this is my first patch, I thought it would be a good exercise for me. OK, as long as you understand that the patch should not be applied. It might be valuable from only one person is not enough. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Adding a --quiet option to initdb
Bruce Momjian pgman@candle.pha.pa.us writes: Devrim GUNDUZ wrote: Hi, On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote: Devrim GUNDUZ [EMAIL PROTECTED] writes: Attached is a patch which adds --quiet and --q option to initdb. Why is this a good idea? I was playing with 8.2 RPM init script and thought that instead of directing the output to /dev/null, it would be better to use a command line option for that. Also, we are designing a new installer project and --quiet might help us. OK, as long as you understand that the patch should not be applied. It might be valuable from only one person is not enough. I always wondered why the Redhat init scripts thought it was a clever idea to redirect the output to /dev/null. It seems like a pessimal user interface choice. Every time I have to work with a Redhat machine where Postgres isn't starting up the first thing I have to do is edit the init script so I can what the problem is. -- greg ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Adding a --quiet option to initdb
Devrim GUNDUZ wrote: Hi, On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote: Devrim GUNDUZ [EMAIL PROTECTED] writes: Attached is a patch which adds --quiet and --q option to initdb. Why is this a good idea? I was playing with 8.2 RPM init script and thought that instead of directing the output to /dev/null, it would be better to use a command line option for that. Also, we are designing a new installer project and --quiet might help us. I would rise this idea in -hackers before providing a patch, but since this is my first patch, I thought it would be a good exercise for me. Regards, Most *nix commands are quiet by default. Most windows commands are verbose and some of them can be made to shut up using special '--quite' like options. Other can't even do that. Personally, I think initdb (and most other commands as well) should be silent unless something goes wrong or unless I explicitly tell it to be verbose. In other words, don't repeat bad practices from Windows by introducing --quiet. Make it completely silent by default instead and then introduce a --verbose. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Adding a --quiet option to initdb
Greg Stark [EMAIL PROTECTED] writes: I always wondered why the Redhat init scripts thought it was a clever idea to redirect the output to /dev/null. It seems like a pessimal user interface choice. Every time I have to work with a Redhat machine where Postgres isn't starting up the first thing I have to do is edit the init script so I can what the problem is. Yeah, that's finally fixed in the latest versions. The problem was that sending the postmaster log into a file wasn't a good long-term idea because of the lack of any way to rotate the log. Current RPMs set up redirect_stderr with some reasonable rotation options instead. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Adding a --quiet option to initdb
On Wed, 2006-01-25 at 19:23 +0100, Thomas Hallgren wrote: Make it completely silent by default instead and then introduce a --verbose. +1. I imagine initdb is usually ran interactively, so I don't think having the extra output is a big issue considering the normal case, but I think the If you want it, ask for it idea that Thomas is proposing is the right way. Why should initdb give it [processing information] to the user if the user didn't request it in the first place? For applications that want to automate the initdb process in a GUI-way or whatnot, the output [of initdb] isn't likely to be a very elegant aspect of the environment the developer would be trying to create, but they are, more or less, stuck with getting it if they wish to provide their user with more informative feedback about the ongoing process. While for Devrim's case, it would be overkill, but what about a libinitdb, or some sort authoritative source of processing steps in order to initialize a new database location that other applications could make easier use of? -- Regards, James William Pye iCrossing Privileged and Confidential Information This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information of iCrossing. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
