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
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: [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: [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
