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)-
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
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
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
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
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
int
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 info
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
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
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 i
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 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
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 t
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 po
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 ou
Bruce Momjian 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 wi
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 inst
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/nul
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
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
20 matches
Mail list logo
