Re: reindexdb command utlility

Hello Postgres team,

I used wanted to point out the the ( -q, --quiet ) parameter for
reindexdb command utility does not work.
Also reindexdb writes NOTICE to standard err for every table it
reindexes which makes it really hard to use in script as it always
produces an "errror". :-)

If this is the way it should work I would be interested in an
explanation. =)

Thank you for a wonderful database!

Regards,
Henrik

> I used wanted to point out the the ( -q, --quiet ) parameter for
> reindexdb command utility does not work.
Actually it is *not* a bug. The NOTICE is printed by the REINDEX
command; reindexdb is just a wrapper around REINDEX command. If you
set up 'client_min_messages' in postgresql.conf, you don't get those
'annoying' messages.

> Also reindexdb writes NOTICE to standard err for every table it
> reindexes which makes it really hard to use in script as it always
> produces an "errror". :-)
>
You can always ignore NOTICE. grep is your friend. :-)

Looking at the code, IMHO we could raise the ereport from NOTICE to
INFO (see the patch attached). None of the scripts actually raise
NOTICEs if it succeeds.

Comments?

--
Euler Taveira de Oliveira
http://www.timbira.com/

31 maj 2006 kl. 03:47 skrev Euler Taveira de Oliveira:

>> I used wanted to point out the the ( -q, --quiet ) parameter for
>> reindexdb command utility does not work.
> Actually it is *not* a bug. The NOTICE is printed by the REINDEX
> command; reindexdb is just a wrapper around REINDEX command. If you
> set up 'client_min_messages' in postgresql.conf, you don't get those
> 'annoying' messages.
I'll take a look at that. I have to make sure that I don't need it
somewhere else first. :-)
>
>> Also reindexdb writes NOTICE to standard err for every table it
>> reindexes which makes it really hard to use in script as it always
>> produces an "errror". :-)
>>
> You can always ignore NOTICE. grep is your friend. :-)
True, but usually I like to have my ERROR messages to stderr and INFO
to stdout.

> Looking at the code, IMHO we could raise the ereport from NOTICE to
> INFO (see the patch attached). None of the scripts actually raise
> NOTICEs if it succeeds.
>
> Comments?
INFO sounds like a good idea. What do you think about sending INFO to
stdout instead of stderr? (As it seems that ereport() automagically
sends the message to stderr)

Cheers,
Henrik
>
>
> --
> Euler Taveira de Oliveira
> http://www.timbira.com/
> <a.diff>

Henrik Zagerholm wrote:

> >You can always ignore NOTICE. grep is your friend. :-)
> True, but usually I like to have my ERROR messages to stderr and INFO
> to stdout.
>
But it's not true in PostgreSQL. All ereport() messages are sent to
stderr. In some scripts, the -e (echo) is used to print command to
stdout. Like I said, you need to "| grep -v" your stderr output.

--
Euler Taveira de Oliveira
http://www.timbira.com/

Patch applied. Thanks.

---------------------------------------------------------------------------

Euler Taveira de Oliveira wrote:
> > I used wanted to point out the the ( -q, --quiet ) parameter for
> > reindexdb command utility does not work.
> Actually it is *not* a bug. The NOTICE is printed by the REINDEX
> command; reindexdb is just a wrapper around REINDEX command. If you
> set up 'client_min_messages' in postgresql.conf, you don't get those
> 'annoying' messages.
>
> > Also reindexdb writes NOTICE to standard err for every table it
> > reindexes which makes it really hard to use in script as it always
> > produces an "errror". :-)
> >
> You can always ignore NOTICE. grep is your friend. :-)
>
> Looking at the code, IMHO we could raise the ereport from NOTICE to
> INFO (see the patch attached). None of the scripts actually raise
> NOTICEs if it succeeds.
>
> Comments?
>
>
> --
> Euler Taveira de Oliveira
> http://www.timbira.com/

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Patch applied. Thanks.

Why is this an improvement? AFAIR an INFO message is *not suppressible*
by adjusting client_min_messages, therefore this makes the system more
chatty not less so. It certainly doesn't do anything to address the
original complaint.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Patch applied. Thanks.
>
> Why is this an improvement? AFAIR an INFO message is *not suppressible*
> by adjusting client_min_messages, therefore this makes the system more
> chatty not less so. It certainly doesn't do anything to address the
> original complaint.

I thought it needed changing for consistency. Shouldn't status messages
like this be INFO:

test=> REINDEX DATABASE test;
NOTICE: table "pg_class" was reindexed
NOTICE: table "sql_languages" was reindexed
NOTICE: table "sql_packages" was reindexed
NOTICE: table "sql_parts" was reindexed

If I do VACUUM VERBOSE, those messages are INFO.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I thought it needed changing for consistency. Shouldn't status messages
> like this be INFO:
> test=> REINDEX DATABASE test;
> NOTICE: table "pg_class" was reindexed

> If I do VACUUM VERBOSE, those messages are INFO.

Yeah, *only because you said VERBOSE*. When we implemented the current
elog level scheme, we designed INFO as non-suppressible so that it would
mimic the previous behavior of VACUUM VERBOSE.

If REINDEX had a VERBOSE option, it would make sense to put out the
messages as INFO when VERBOSE was used. But it doesn't (and this is
not a request to add one). Without VERBOSE, I think it's utterly
unacceptable to force the messages out regardless of client_min_messages.
NOTICE was a reasonable level, maybe LOG would be a better one. But
not INFO.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I thought it needed changing for consistency. Shouldn't status messages
> > like this be INFO:
> > test=> REINDEX DATABASE test;
> > NOTICE: table "pg_class" was reindexed
>
> > If I do VACUUM VERBOSE, those messages are INFO.
>
> Yeah, *only because you said VERBOSE*. When we implemented the current
> elog level scheme, we designed INFO as non-suppressible so that it would
> mimic the previous behavior of VACUUM VERBOSE.
>
> If REINDEX had a VERBOSE option, it would make sense to put out the
> messages as INFO when VERBOSE was used. But it doesn't (and this is
> not a request to add one). Without VERBOSE, I think it's utterly
> unacceptable to force the messages out regardless of client_min_messages.
> NOTICE was a reasonable level, maybe LOG would be a better one. But
> not INFO.

OK, reverted.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:

> Yeah, *only because you said VERBOSE*. When we implemented the current
> elog level scheme, we designed INFO as non-suppressible so that it would
> mimic the previous behavior of VACUUM VERBOSE.
>
Agreed.

> If REINDEX had a VERBOSE option, it would make sense to put out the
> messages as INFO when VERBOSE was used. But it doesn't (and this is
> not a request to add one). Without VERBOSE, I think it's utterly
> unacceptable to force the messages out regardless of client_min_messages.
> NOTICE was a reasonable level, maybe LOG would be a better one. But
> not INFO.
>
LOG would be a good option, but maybe a small hack in reindexdb is
better.

--
Euler Taveira de Oliveira
http://www.timbira.com/

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

Euler Taveira de Oliveira wrote:
> Tom Lane wrote:
>
> > Yeah, *only because you said VERBOSE*. When we implemented the current
> > elog level scheme, we designed INFO as non-suppressible so that it would
> > mimic the previous behavior of VACUUM VERBOSE.
> >
> Agreed.
>
> > If REINDEX had a VERBOSE option, it would make sense to put out the
> > messages as INFO when VERBOSE was used. But it doesn't (and this is
> > not a request to add one). Without VERBOSE, I think it's utterly
> > unacceptable to force the messages out regardless of client_min_messages.
> > NOTICE was a reasonable level, maybe LOG would be a better one. But
> > not INFO.
> >
> LOG would be a good option, but maybe a small hack in reindexdb is
> better.
>
>
> --
> Euler Taveira de Oliveira
> http://www.timbira.com/

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Patch applied. Thanks.

---------------------------------------------------------------------------

Euler Taveira de Oliveira wrote:
> Tom Lane wrote:
>
> > Yeah, *only because you said VERBOSE*. When we implemented the current
> > elog level scheme, we designed INFO as non-suppressible so that it would
> > mimic the previous behavior of VACUUM VERBOSE.
> >
> Agreed.
>
> > If REINDEX had a VERBOSE option, it would make sense to put out the
> > messages as INFO when VERBOSE was used. But it doesn't (and this is
> > not a request to add one). Without VERBOSE, I think it's utterly
> > unacceptable to force the messages out regardless of client_min_messages.
> > NOTICE was a reasonable level, maybe LOG would be a better one. But
> > not INFO.
> >
> LOG would be a good option, but maybe a small hack in reindexdb is
> better.
>
>
> --
> Euler Taveira de Oliveira
> http://www.timbira.com/

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +