Re: elog() patch - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: elog() patch |
Date | |
Msg-id | 200202281558.g1SFwHI21172@candle.pha.pa.us Whole thread Raw |
In response to | Re: elog() patch (Peter Eisentraut <peter_e@gmx.net>) |
Responses |
Re: elog() patch
|
List | 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@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
pgsql-hackers by date: