Merge pull request quarkusio#36553 from rolfedh/pinning-obsolete

Add note that pinning cases section is historical information.

docs/src/main/asciidoc/virtual-threads.adoc

@@ -134,13 +134,16 @@ According to link:{vthreadjep}[JEP 425] this can happen in two situations:
 - when it executes a blocking operation inside a native method or a foreign function
 
 It can be reasonably easy to avoid these situations in your code, but verifying every dependency you use is hard.
-Typically, while experimenting with virtual threads, we realized that old versions of the link:{pgsql-driver}[postgresql-JDBC driver]
-results in frequent pinning.
+Typically, while experimenting with virtual threads, we realized that versions older than 42.6.0 of the link:{pgsql-driver}[postgresql-JDBC driver] result in frequent pinning.
 Most JDBC drivers still pin the carrier thread.
-Even worse, lots of widespread libraries are pinning and would require code changes.
+Even worse, many libraries require code changes.
 
 For more information, see link:https://quarkus.io/blog/virtual-thread-1/[When Quarkus meets Virtual Threads]
 
+IMPORTANT: This information about pinning cases applies to PostgreSQL JDBC driver 42.5.4 and earlier.
+For PostgreSQL JDBC driver 42.6.0 and later, virtually all synchronized methods have been replaced by reentrant locks.
+For more information, see the link:https://jdbc.postgresql.org/changelogs/2023-03-17-42.6.0-release/[Notable Changes] for PostgreSQL JDBC driver 42.6.0.
+
 [[pooling]]
 ==== The pooling case
 Some libraries are using `ThreadLocal` as an object pooling mechanism.