Re: elog() patch

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

In response to

Responses

Browse pgsql-hackers by date

  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