From: fluca1978 at infinito.it (Luca Ferrari)
Date: Tue, 27 Jul 2010 09:00:33 +0200
Subject: [Pljava-dev] pljava error logging levels
In-Reply-To: <6C857822-01B2-417D-8CFE-04309DB12A98@greenplum.com>
References: <3F082C5B-116B-4CB7-9755-B3D306B8C942@greenplum.com>
	<201007261200.05370.fluca1978@infinito.it>
	<6C857822-01B2-417D-8CFE-04309DB12A98@greenplum.com>
Message-ID: <201007270900.34396.fluca1978@infinito.it>

On Monday, July 26, 2010 11:08:34 pm Caleb Welton's cat walking on the 
keyboard wrote:
> Well the original question I asked was "Why does PL/Java try to filter log
> levels at all?".  If we simply disabled the log filtering from PL/Java and
> let the log filtering happen naturally in Postgres then all of these
> problems just go away.
> 
> This could be accomplished using the attached patch.
> 
> Alternatively, significant improvement could be made by at least setting
> the log level correctly at init time by checking both log_min_messages AND
> client_min_messages and setting the log level to whichever is FINER
> grained logging.   But since this still doesn't address changes to the
> GUCs over time it seems like a less desirable approach.


The patch is doing exactly this: choosing the finer logging level between 
client and log_min_messages, but this is a static setup, as you say. I think 
we should have a way to get notified of when the server settings have changed. 
Moreover, what happen if you change the client_min_messages within an 
interactive session before calling a Java method? With a setup done at the 
initialization phase we could have the same problem of logs missed.
So I guess we should re-initialize log levels at least as soon as the handler 
is created (not only at the jvm initialization) and maybe each time (or each 
n-times) the publish method is called. That's why I proposed a threaded 
solution. However, the best is to be notified about changes in the configuration 
of the session and/or of the server.

Luca