Re: New driver logging proposal

Yes, I agree with Vladimir, I don't like the idea of a wrapper
(anti-pattern), JUL can be mostly fine if configured correctly.

Most performance degradation claims are related to using others logging
frameworks and using a bridge to redirect from JUL to SLF4J and that by
design it can not impersonate JUL api.

The focus should be that when the logging is disabled it don't introduce
some degradation when using slf4j+some other framework (IMO there is where
an impact in performance can be found), in other words, when it's disabled,
it's truly disabled.

The second focus should be make the logging useful for end users, most of
the logging is for developers and related to the protocol, having fixed
categories like the proposed ones can help a lot here, and as contradictory
as it seems there is needed a lot more log messages. In the mssql-jdbc for
instance there is a lot more verbose messages and have a lot entering
and exiting
messages (not the approach I would use but it's there).

In the issue #788 I have to recompile the driver with more log messages
simply because the ones that are there are simply not enough to found a
problem in the code.

In the mssql-jdbc the connection id (and statements and resultsets) are
simply incremental id, and should be more than enough to identify calls
related to a connection/statement/resultset, I mean if you call a prepared
statement for instance and you set parameters to it, in a highly concurrent
enviroment a setString() related to a prepared statement can seems that was
called by another prepared statement in the log.

So far I have seen more benefits of using JUL than claims of performance
degradation (and most of the claims are when using slf4j bridge). Of course
there is more to do, it might be not the best choice but was that or
introduce a optional dependency of SLF4J (wich is a bad idea based on the
SLF4J developers https://www.slf4j.org/faq.html#optional_dependency) or
simply introduce a direct dependency of SLF4J making a forced used of a
dependency that not many want. This is like the chicken-egg problem.

On Sun, Apr 9, 2017 at 3:54 PM, Vladimir Sitnikov <
sitnikov(dot)vladimir(at)gmail(dot)com> wrote:

> Daniel,
>
> I wonder if adding "logging=true" property is required to meed the
> performance requirements at all.
> I would like to refrain from adding new configuration options.
>
> What bothers me with "replace jul with abc" approach is it will be yet
> another 100500+lines change that is hard to review.
> I wonder how far can we go with keeping jul interfaces. Is it
> possible/enough to just add relevant "log level caching at the
> resultset/etc levels"?
>
> Daniel>Show connection IDs in the log messages to identify connections,
> and not in logging categories
>
> ConnectionIDs are unpredictable, so I can hardly imagine a case when
> end-user would activate logging based on the connection id (e.g. enable
> debug for a specific ID only).
> On the other hand, having something like "org.postgresql.sql.DB_NAME.USER_NAME.CONN_ID"
> as a logging category could make sense.
>
> Vladimir
>
>>