Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut wrote:
> Bruce Momjian writes:
> 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

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

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


pgsql-hackers by date

Next:From: Hannu KrosingDate: 2002-02-28 16:21:34
Subject: Re: Oracle vs PostgreSQL in real life
Previous:From: F HarvellDate: 2002-02-28 15:00:40
Subject: Re: eWeek Poll: Which database is most critical to

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group