[Pljava-dev] pljava error logging levels

On Jul 27, 2010, at 12:00 AM, Luca Ferrari wrote:

> 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.
>
> 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 direct your attention to the line:

props.setProperty(".level", getPgLevel().getName());

Which my patch removed from ELogHandler.init().

By removing this property setting the instantiated log handler no longer
filters log messages as they come in and all log messages get published
and passed to Postgres.

That alone fixes the problem. At which point getPgLevel() becomes
largely obsolete, but I figured I would "fix" it as well since it was defined
as a public method and it was conceivable that someone might be
using it. Removing and/or deprecating getPgLevel() would also be an option.

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

That was never an issue to begin with. Since setup occurs on the first function call
any GUC changes that occur prior to that simply look like the normal server settings.

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

I didn't like the threaded solution because behavior would be non-deterministic
depending on thread execution timing.

> However, the best is to be notified about changes in the configuration
> of the session and/or of the server.

I think this and not having Java pre-filter the messages are roughly equivalent,
and since not pre-filtering seemed less complicated it was what I did in the patch.