[Pljava-dev] pljava error logging levels

From: fluca1978 at infinito(dot)it (Luca Ferrari)
To:
Subject: [Pljava-dev] pljava error logging levels
Date: 2010-07-21 13:05:50
Message-ID: 201007211505.50676.fluca1978@infinito.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

On Monday, July 12, 2010 10:47:27 pm Caleb Welton's cat walking on the
keyboard wrote:
> Hello, I had several questions about the ELogHandler in pljava, was hoping
> someone could comment on it.
>
> In postgres there is code to handle the filtering of logging levels and
> this is controlled by several gucs for different types of logging. For
> instance log_min_messages is used to control the logging level that gets
> written to the log file, while client_min_messages is used to control the
> logging level that gets displayed to the client. Looking at
> ELogHandler.java I see that pljava bases its own decision on how the JVM
> should filter logging level based on the setting of log_min_messages <b>at
> the time of JVM initialization</b>.
>

Not sure to get it straight, however what I see is that:
1) the Backend.c has a method to set the log level that is used in JNICalls.c
in the printStackTraceMethod using DEBUG1 as thresold to print out logs (this
sounds ok to me);
2) in ELogHandler.java the publish method calls the Backend.log method, that
resolves to a native one that uses the ereport method in the Backend.c with
the declared level.

So what can happen is that, once the pljava process has started, someone on
the server increases the logging level (log_min_messages) and pljava continues
to use the old value. This is due to the fact that the correct reading of the
log_min_messages is done only in the init() method (more exactly in the
getPgLevel one). If this is the issue you are talking about the only solution
I see is to correct the Backend.log method in order to call the getPgLevel
before issuing the log record. However, this should not be a problem, since
the logging system of the server should ignore any message with a wrong
logging category. So, let's say you must log an DEBUG3 message and the server
has an INFO level, the message should be ignored at all, even if issued. When
the log_min_messages is raised to DEBUG3, another message should be logged.
Isn't it?

> Question) Why does PLJava even try to install its own log level filtering
> when the Postgres logger already is handling this?
>

I don't get this, in my opinion the pljava is not installing a filter handler,
but a translation handler from the Java levels to the Pg ones.

> In Java there are the following logging levels, from highest to lowest:
> SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST In Postgres the logging
> levels, from highest to lowest are: PANIC, FATAL, ERROR, WARNING, NOTICE,
> INFO, LOG, DEBUG1, DEBUG2, ...
>
> pljava creates a mapping as follows:
> SEVERE => ERROR
> WARNING => WARNING
> INFO => INFO
> CONFIG => NOTICE

Right, pg's notice is mapped over Java's config, that is higher than INFO-
>INFO. Moreover I don't understand why fatal is mapped to OFF and not to
SEVERE. Maybe the patch I attach can fix the problem, but since we are mapping
more levels than those available in Java we have some clashes.

Luca

-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.patch
Type: text/x-patch
Size: 2381 bytes
Desc: not available
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20100721/d710e9d0/attachment.bin>

In response to

Responses

Browse pljava-dev by date

  From Date Subject
Next Message Caleb Welton 2010-07-22 18:23:58 [Pljava-dev] pljava error logging levels
Previous Message Luca Ferrari 2010-07-21 10:22:51 [Pljava-dev] possible patch for cancelling a trigger operation (Luca Ferrari)