Thread: 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/
Attachment
On Wed, 2006-01-25 at 16:08 +0200, Devrim GUNDUZ wrote:
> 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.
>
Devrim,
What's wrong with just sending stdout to /dev/null? If that eats error
messages too then we should probably fix initdb to send those to stderr.
But if we are going to do this, then I also noticed a couple of things:
. you should explicitly initialize the quiet variable, in keeping with
the style of the others nearby.
. the idiom
if (! quiet)
{
fputs(_("some message"),stdout);
fflush(stdout);
}
should not be endlessly repeated. Make it a macro or a function.
I wonder if we can just set rid of all those fflush() calls by
unbuffering stdout with a single call to setbuf() or setvbuf()?
cheers
andrew
Hi Andrew,
On Wed, 2006-01-25 at 09:28 -0500, Andrew Dunstan wrote:
> What's wrong with just sending stdout to /dev/null? If that eats error
> messages too then we should probably fix initdb to send those to
> stderr.
We have the same options with reindexdb, for example. I think a command
line option
> But if we are going to do this, then I also noticed a couple of
> things:
>
> . you should explicitly initialize the quiet variable, in keeping with
> the style of the others nearby.
Oh, I've missed it. Patch updated.
> . the idiom
>
> if (! quiet)
> {
> fputs(_("some message"),stdout);
> fflush(stdout);
> }
>
> should not be endlessly repeated. Make it a macro or a function.
I'm looking at it now.
Thanks for your comments. I'll provide a new patch soon, which will also
include Alvaro's suggestion about surpression both header and footer
(--make-initdb-really-quiet-mode :) )
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/
Hi, On Wed, 2006-01-25 at 17:22 +0200, Devrim GUNDUZ wrote: > On Wed, 2006-01-25 at 09:28 -0500, Andrew Dunstan wrote: > > What's wrong with just sending stdout to /dev/null? If that eats > error > > messages too then we should probably fix initdb to send those to > > stderr. > > We have the same options with reindexdb, for example. I think a > command > line option (Opps...) We have the same options with reindexdb, for example. I think a command line options is better and required. 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/
Devrim GUNDUZ wrote: > We have the same options with reindexdb, for example. reindexdb and friends inherited that option from psql. On a green field, they probably wouldn't have it. psql has more complex semantics, so it's not clear whether that's the same thing. > I think a command line options is better and required. I think we need more proof of that than a use case involving taking screen shots. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Devrim GUNDUZ <devrim@commandprompt.com> writes:
> Attached is a patch which adds --quiet and --q option to initdb.
Why is this a good idea?
regards, tom lane
Hi, On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote: > Devrim GUNDUZ <devrim@commandprompt.com> 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/
Peter Eisentraut wrote: > Devrim GUNDUZ wrote: > > We have the same options with reindexdb, for example. > > reindexdb and friends inherited that option from psql. On a green > field, they probably wouldn't have it. psql has more complex > semantics, so it's not clear whether that's the same thing. > > > I think a command line options is better and required. > > I think we need more proof of that than a use case involving taking > screen shots. Agreed on both points. -- 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
Hi, On Wed, 2006-01-25 at 16:32 +0100, Peter Eisentraut wrote: > > I think a command line options is better and required. > > I think we need more proof of that than a use case involving taking > screen shots. I've just explained my points as a reply to Tom's mail. 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/
Devrim GUNDUZ wrote: > Hi, > > On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote: > > Devrim GUNDUZ <devrim@commandprompt.com> 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
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 <devrim@commandprompt.com> 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
Devrim GUNDUZ wrote: > Hi, > > On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote: >> Devrim GUNDUZ <devrim@commandprompt.com> 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
Devrim GUNDUZ wrote: > 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. This is merely an opinion. On what technical grounds would it be "better"? (I happen to agree with Greg's post that the init script shouldn't be silent in the first place. I'm also of the opinion that initdb shouldn't be run from the init script, but that's a different topic.) -- Peter Eisentraut http://developer.postgresql.org/~petere/
Greg Stark <gsstark@mit.edu> 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
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 informationof iCrossing. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intendedrecipient, please contact the sender by reply email and destroy all copies of the original message.
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. -- Peter Eisentraut http://developer.postgresql.org/~petere/
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 jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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
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
Thomas Hallgren <thomas@tada.se> 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
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
Thomas Hallgren wrote: > 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. > >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. 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. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "I can't go to a restaurant and order food because I keep looking at the fonts on the menu. Five minutes later I realize that it's also talking about food" (Donald Knuth)
Alvaro Herrera <alvherre@alvh.no-ip.org> 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
Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> 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)
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
> 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/