From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: elog() patch |
Date: | 2002-02-28 15:58:16 |
Message-ID: | 200202281558.g1SFwHI21172@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2002-02-28 16:21:34 | Re: Oracle vs PostgreSQL in real life |
Previous Message | F Harvell | 2002-02-28 15:00:40 | Re: eWeek Poll: Which database is most critical to |