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

From Peter Eisentraut
Subject Re: elog() patch
Date
Msg-id Pine.LNX.4.30.0202280036270.688-100000@peter.localdomain
Whole thread Raw
In response to elog() patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: elog() patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: elog() patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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.

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

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

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

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

Why?

> Remove debug_level GUC parameter

Why?

> Bootstrap mode now has a -d that requires an argument, like postmaster

OK

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

Why?

-- 
Peter Eisentraut   peter_e@gmx.net



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: elog() patch
Next
From: Denis Perchine
Date:
Subject: Re: eWeek Poll: Which database is most critical to your