Re: elog() patch - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: elog() patch
Date
Msg-id 200202281558.g1SFwHI21172@candle.pha.pa.us
Whole thread Raw
In response to Re: elog() patch  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: elog() patch  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > REALLYFATAL => PANIC
> > STOP => PANIC
> 
> The annoying thing about the choice PANIC is that while the previous
> suggestions may not give you the most accurate idea about what the action
> really is, PANIC is just about the worst possible choice, because "panic"
> is *no* action at all, it's just a state of mind.

Yes, but PANIC was chosen by vote, and it does match the kernel-level
description.

> > New INFO level the prints to client by default
> 
> I doubt this idea.  NOTICE should really print to the client only.  This
> again comes down to the user-level errors vs. server-side errors issue.
> But INFO doesn't convey either of these meanings.

We could call it TIP or something like that. I think INFO is used
because it isn't a NOTICE or ERROR or something major.  It is only INFO.
It is neutral information.

> > DEBUG removed, kept as backward compatible (will be added near 7.3)
> > DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1 added
> > DebugLvl removed in favor of new DEBUG[1-5] symbols
> 
> Since you've made us stick with 1-5, are there any meanings attached to
> those numbers?

5 is max, 1 is for higher level messages.  I just followed what was
already there.  We can adjsut these.

> > New server_min_messages GUC parameter with values DEBUG[5-1], INFO, LOG, ...
> > New client_min_messages GUC parameter with values DEBUG[5-1], LOG, INFO, ...
> 
> Now that is *really* confusing.  Two different ways to number the same
> things.

Sure is, but it was agreed to by the group discussing it as the cleanest
solution.  postgresql.conf has these levels documented, as does the SGML
docs.

> > Postmaster -d flag effects only postmaster message, not backend messages
> 
> Why?

This allows you to see postmaster connection-level debug stuff without
the query debug stuff from the backend. If you want both, you have to
set the postgres -d flag too.  Seemed clearer but I can remove it if
people don't want it.

> > Remove debug_level GUC parameter
> 
> Why?

No longer needed with new DEBUG* levels.

> > This clears the -d debug level on backend start.  Is that done correctly?
> 
> Why?

Again, seemed clearer.  The way things are in the patch, you can't do -d
0 in the backend to turn off debug on the backend, so you have to
explicitly enable it. Of course, with these new GUC paramaters, the need
for -d is less anyway, and you can see all the messages in your client
if you wish.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Marc Munro
Date:
Subject: Re: Point in time recovery: recreating relation files
Next
From: Antonio Sergio de Mello e Souza
Date:
Subject: Re: Oracle vs PostgreSQL in real life