Message-ID: From: "Sanne (@Sanne)" To: "pgjdbc/pgjdbc" Date: Fri, 27 Jun 2025 14:36:00 +0000 Subject: [pgjdbc/pgjdbc] issue #3693: Overhead of uncontended use of ResourceLock List-Id: X-GitHub-Author-Id: 42573 X-GitHub-Author-Login: Sanne X-GitHub-Issue: 3693 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-State: open X-GitHub-Type: issue X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3693 Content-Type: text/plain; charset=utf-8 **Describe the issue** I'm running some benchmarks on a Quarkus application using Hibernate ORM and pgjdbc. While I admit there are also other bottlenecks which worry me more than this one, it's quite noticeable on flamegraphs that we spend significant CPU cycles on `ResourceLock.obtain` and `ResourceLock.close`. While the application is heavily parallel and using many threads, the general model is that a single HTTP request is being handled within the confines of a single backend thread: there is zero contention on the pgjdbc core resources such as `PgConnection` and `QueryExecutorBase`. I'm sure that - in our design - we actually don't need these locks at all. But I appreciate the JDBC spec requirement and the need to accommodate for other architectures. I see multiple possibilities, not sure what you'd find acceptable: 1. Introduce a global flag (perhaps even a JVM property?) which fully disables locking: make it responsibility of the system architects to play with such a setting at their own risk. 2. Have a detailed look at some of them and try to improve the locking patterns as I have the impression that some of them are unneccessary. For example, I *think* that in the case of `PgConnection`.`clearWarnings` one could simply remove the lock: it's guarding a `checkClosed()` invocation (which several other methods perform w/o the lock so seems acceptable) and also `queryExecutor.getWarnings();` : but the query executor has its own lock so it's definitely redundant. The method is also setting `firstWarning` to `null` but we'd be better off in replacing this with a volatile. This is just an example, I see plenty of methods which seem to lock excessively and could be simplified. I'd be happy to provide patches - just checking if these approaches would be acceptable? Attaching a flamegraph as well, in case someone is interested to see them: [flamegraph_quarkus_db_256.zip](https://github.com/user-attachments/files/20950646/flamegraph_quarkus_db_256.zip)