Vert.x SQL Client Pool and PostgreSQL Idle Connection Timeout: Determining Responsibility for Stale Connection Eviction

The goal is to decide whether the Vert.x SQL client connection pool should proactively evict idle connections after a period of inactivity or rely solely on PostgreSQL's idle-in-transaction session timeout to avoid intermittent pool exhaustion during burst traffic.

Constraints include using Vert.x 4 with its HikariCP‑backed pool (configurable maxSize, idleTimeout, leakDetectionThreshold), observing pool saturation via Micrometer metrics, avoiding thread starvation by not oversizing the pool relative to the Vert.x worker executor, and recognizing that aggressive leak detection thresholds can generate false positives in environments with legitimate long‑running queries. PostgreSQL‑side timeouts may vary across versions, adding another layer of variability.

Uncertainty remains about whether proactive eviction complements or conflicts with the database's own timeout mechanism, which can lead to differing exhaustion symptoms across Vert.x releases and complicate diagnosis when leak‑detection logs are silent.

Should the Vert.x SQL client pool enable idleTimeout‑based eviction as the primary method for clearing stale connections, or should it disable idle eviction and defer entirely to PostgreSQL's idle_in_transaction_session_timeout?
How does the interaction between Vert.x leakDetectionThreshold and PostgreSQL statement_timeout influence the visibility of pool exhaustion during intermittent high‑load bursts?