Re: elog() patch

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: elog() patch
Дата
Msg-id Pine.LNX.4.30.0202280036270.688-100000@peter.localdomain
обсуждение исходный текст
Ответ на elog() patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: elog() patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: elog() patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: elog() patch
Следующее
От: Denis Perchine
Дата:
Сообщение: Re: eWeek Poll: Which database is most critical to your