Adding a --quiet option to initdb

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 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.

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