Kevin Y
08/27/2026, 10:20 PMWITH deduped_source AS query we got a connection leak exception.
2026-08-27 18:43:19 destination WARN HikariPool-1:housekeeper c.z.h.p.ProxyLeakTask(run):85 Connection leak detection triggered for org.postgresql.jdbc.PgConnection@18907fb3 on thread DefaultDispatcher-worker-3, stack trace follows java.lang.Exception: Apparent connection leak detected
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:99) ~[HikariCP-7.0.2.jar:?]
at io.airbyte.integrations.destination.postgres.client.PostgresAirbyteClient.execute(PostgresAirbyteClient.kt:455) ~[io.airbyte.airbyte-integrations.connectors-destination-postgres.jar:?]
at io.airbyte.integrations.destination.postgres.client.PostgresAirbyteClient.upsertTable-Fn9JJlk(PostgresAirbyteClient.kt:171) ~[io.airbyte.airbyte-integrations.connectors-destination-postgres.jar:?]
at io.airbyte.cdk.load.table.directload.DirectLoadTableDedupStreamLoader.teardown(DirectLoadTableStreamLoader.kt:129) ~[bulk-cdk-core-load-1.0.20.jar:?]
at io.airbyte.cdk.load.dataflow.DestinationLifecycle$finalizeIndividualStreams$2$1$1.invokeSuspend(DestinationLifecycle.kt:96) ~[bulk-cdk-core-load-1.0.20.jar:?]
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) ~[kotlin-stdlib-2.1.10.jar:2.1.10-release-473]
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104) ~[kotlinx-coroutines-core-jvm-1.8.1.jar:?]
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584) ~[kotlinx-coroutines-core-jvm-1.8.1.jar:?]
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:811) ~[kotlinx-coroutines-core-jvm-1.8.1.jar:?]
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:715) ~[kotlinx-coroutines-core-jvm-1.8.1.jar:?]
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:702) ~[kotlinx-coroutines-core-jvm-1.8.1.jar:?]
Stack Trace: java.lang.Exception: Apparent connection leak detected
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:99)
at io.airbyte.integrations.destination.postgres.client.PostgresAirbyteClient.execute(PostgresAirbyteClient.kt:455)
at io.airbyte.integrations.destination.postgres.client.PostgresAirbyteClient.upsertTable-Fn9JJlk(PostgresAirbyteClient.kt:171)
at io.airbyte.cdk.load.table.directload.DirectLoadTableDedupStreamLoader.teardown(DirectLoadTableStreamLoader.kt:129)
at io.airbyte.cdk.load.dataflow.DestinationLifecycle$finalizeIndividualStreams$2$1$1.invokeSuspend(DestinationLifecycle.kt:96)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:811)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:715)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:702)
What could we even do about that?kapa.ai
08/27/2026, 10:20 PMApparent connection leak detected from HikariCP does not necessarily mean an actual leak occurred. HikariCP fires this when a single connection is held longer than the leakDetectionThreshold, which in the postgres destination is set to DATA_SOURCE_CONNECTION_TIMEOUT_MS + 10000L. [PostgresBeanFactory]
The WITH deduped_source AS ... upsert CTE is a long-running maintenance query (dedup finalization). On large Salesforce tables, it can exceed the threshold, triggering the warning while the connection is still legitimately in use inside PostgresAirbyteClient.execute. [PostgresAirbyteClient]
Related Known Issues 1. statement_timeout cancellations â If your Postgres server or connection pooler (e.g., Supabase's pooler) enforces a low statement_timeout, the long-running upsert can be actively cancelled with ERROR: canceling statement due to statement timeout. PR #82251 fixes this (in connector version 3.0.14+) by setting SET SESSION statement_timeout = 0 on each pooled connection. [fix PR]
2. `COUNT()` stalls on large tables* â There's an open issue (#82229) where a full COUNT(*) at sync start causes multi-minute stalls on large tables, which can compound with the upsert timing. [COUNT issue]
What You Can Do 1. Check if the sync actually failed or just warned. If the sync completed successfully, the leak detection warning is cosmetic â the connection was returned to the pool after the query finished.
2. Check for active statement_timeout on your Postgres server. If the upsert is being cancelled (not just slow), you'll see a PSQLException: canceling statement due to statement timeout error. You can override this via jdbcUrlParams in the destination config:options=-c statement_timeout=0Note: connector version 3.0.14+ handles this automatically unless you set it explicitly. [fix PR]
3. Tune PostgreSQL settings for long-running queries, similar to what resolved a large-table issue in another case:work_mem = 72MB
client_connection_check_interval = 30000
tcp_keepalives_idle = 10[GitHub issue #51580]
4. Upgrade the destination-postgres connector to 3.0.14 or later if possible, as the statement_timeout = 0 fix is included there. [fix PR]
The key question is whether the sync is failing (upsert cancelled) or just slow (leak warning only). The stack trace you shared is a WARN, not an ERROR, so the sync may have completed â worth checking the final sync status. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements