Re: elog() patch

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Yes, but PANIC was chosen by vote, and it does match the kernel-level
> > description.
>
> What is the kernel-level description?

Kernel stops, can't continue. kernel panic.

> > > 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.
>
> That's what NOTICE is. NOTICE is only neutral information. NOTICE could
> go to the client by default, whereas if you want something in the server
> log you use LOG. I doubt an extra level is needed.

Notice isn't as neutral. It is for truncation of long identifiers and
stuff like that.

> > > > 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.
>
> I doubt that agreement.

Well, we discussed it on the lists, and no one objected after this
result was found.

> Consider, what and how much I want to debug is really quite independent of
> what amount of regular "neutral" messages I want to see where. The latter
> is a rather permanent administrative decision, whereas the former is a
> temporary decision to isolate problems. A "debug level" is really a
> universal concept in any package, and I hate to see it go.

Well, yes, but unless we want a really complicated setup, we may as well
just emit the neutral messages with the debug. It has to be simple.
There is usually one neutral message per query, if any, so I don't see
the point.

> Secondly, once I have decided how much debugging I want to do, it is
> unlikely that I want to do a different amount of debugging on the client
> and on the server. I can see users becoming confused by this: "I already
> set the debugging level to 5, but I still only see the same messages in
> the client". I think that the current debug_level, plus a new Boolean
> setting "debug_to_client" or such is sufficient and much clearer.

I disagree. The patch gives us clear control over the various levels.
Tom wanted the DebugLvl variable stuff rolled into elog, and I think
this is a very clean solution.

I think Tom's point was that we want to control the independently, and
that is what this does. I think it a valid use.

> As far as the non-debug levels go, there isn't much choice. ERROR and
> above really needs to be communicated to the client anyway. So you might
> be able to tune which one of LOG, INFO, NOTICE goes where. But that's
> about all.

Yes, that is all the options you have for client, ERROR and below.

> > > > 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.
>
> We had wanted to get rid of the discrepancy between postmaster and
> postgres flag, not add new ones.

We now separate them so they act independently.

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