When writing streams into a PostgreSQL database using Full Refresh | Owerwrite, I get the following error : 2026-03-03 041805 destination ERROR type-and-dedupe i.a.c.i.d.j.t.JdbcDestinationHandler(execute):180 Sql e694ef15-1b5d-412f-b9f7-0664cc4b32e8-3c50a088-251c-4c07-a1dd-83af451962d0 failed org.postgresql.util.PSQLException: ERROR: deadlock detected Detail: Process 689105 waits for AccessExclusiveLock on object 2171139 of class 2618 of database 681690; blocked by process 689101. Process 689101 waits for AccessExclusiveLock on object 2171129 of class 2618 of database 681690; blocked by process 689105. Hint: See server log for query details. Airbyte version : 1.7.7 PostgreSQL connector : 2.4.5 How to resolve this ?

The knowledge sources do not explicitly mention this specific deadlock error pattern for Postgres destinations, so the guidance below is partially inferred from how Full Refresh | Overwrite works in Airbyte and from general Postgres behavior. With Full Refresh | Overwrite, Airbyte’s Postgres destination typically recreates the final table each sync (drop/rename pattern) to replace existing data with new data. [Full refresh overwrite] This involves taking strong locks (e.g.,

ACCESS EXCLUSIVE

) on the affected tables. If multiple operations try to acquire conflicting locks in different orders (for example, multiple streams or concurrent syncs), Postgres can detect a deadlock and abort one of them. From the docs: > For our certified database and data warehouse destinations, we will be recreating the final table each sync… at the end dropping the old "final" table, and renaming the new one into place. [Full refresh overwrite] Given that, the most likely causes are: • Multiple streams being written in parallel to the same Postgres database, each trying to drop/rename tables at the same time. • Possibly multiple Airbyte connections or jobs targeting the same schema/tables concurrently. The documentation does not provide a step‑by‑step fix for deadlocks, but based on the described behavior, you can mitigate it by: 1. Avoid concurrent full-refresh overwrites on the same database/schema. Run fewer connections at the same time, or schedule them so that only one heavy Full Refresh | Overwrite job runs at once. 2. Reduce parallelism at the Airbyte level. The connector framework supports a

concurrency_level

concept that controls how many streams/partitions are processed in parallel. [Concurrency level] While the docs don’t state that the Postgres destination exposes this directly in its UI, if you are using any configuration or custom connector YAML that increases concurrency, lowering it (e.g., to a small number instead of many parallel streams) will reduce the chance of lock contention. 3. Consider using a different sync mode where possible. If your use case allows it, switching some streams to Incremental | Append + Deduped can reduce the frequency of full table recreation and thus heavy locks. The docs highlight that incremental modes behave differently from full refresh and are often preferable for ongoing syncs. [Sync modes overview] Because the docs do not include a dedicated “deadlock troubleshooting” section for Postgres destinations, I cannot point you to an official, connector‑specific setting that guarantees to eliminate this error. If the above mitigations don’t help, the next step would be to: • Inspect the Postgres server logs to see the exact SQL statements involved in the deadlock (as suggested by the Postgres error hint). • Share those details with Airbyte support or the community (including your Airbyte version, connector version, and how many connections/streams run in parallel), so they can confirm whether this is a known issue in

destination-postgres

for 1.7.7 / 2.4.5 and suggest a version upgrade or configuration change. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai how to configure environnement variable TD_THREADS used in class FutureUtils into Java CDK ?

I’m sorry, but the provided knowledge sources do not mention the

TD_THREADS

environment variable, the

FutureUtils

class, or how to configure

TD_THREADS

in the Java CDK. The only environment‑variable–related items in the sources are: • How to pass custom environment variables when running connector acceptance tests, via

custom_environment_variables

in the acceptance-test config. [Acceptance tests env] • How to pass environment variables to containers started by the worker (e.g.,

JAVA_TOOL_OPTIONS

,

DEBUG_CONTAINER_IMAGE

, etc.) for debugging. [Debugging containers] Neither of these references

TD_THREADS

or

FutureUtils

, and there is no Java CDK–specific documentation in the supplied material that explains how

TD_THREADS

is read or used. Given this limitation, I can’t reliably tell you: • Whether

TD_THREADS

is actually supported/used by the current Java CDK. • Whether it must be set as a container env var, a config field, or via some other mechanism. If you have access to the connector’s code, the next concrete step would be to: 1. Search in the Airbyte repo (or your connector repo) for

TD_THREADS

and

FutureUtils

to see how the value is read (e.g.,

System.getenv("TD_THREADS")

). 2. Once you know it’s read from the process environment, you can: ◦ Set it on the connector container (e.g., via your deployment manifests or Docker run options), or ◦ For tests, inject it via

custom_environment_variables

in the acceptance-test config as shown in the docs. [Acceptance tests env] But the exact, CDK‑level configuration pattern for

TD_THREADS

is not documented in the provided sources. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.