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

Re: elog() patch

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: elog() patch
Date: 2002-02-28 05:43:49
Message-ID: Pine.LNX.4.30.0202280036270.688-100000@peter.localdomain (view raw or flat)
Thread:
Lists: 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(at)gmx(dot)net


In response to

Responses

pgsql-hackers by date

Next:From: Michael MeskesDate: 2002-02-28 07:04:18
Subject: Re: eWeek Poll: Which database is most critical to your
Previous:From: Denis PerchineDate: 2002-02-28 05:41:03
Subject: Re: eWeek Poll: Which database is most critical to your

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