PostgreSQL

Concurrency limit initialization crashes PostgreSQL runs with UniqueViolation

critical
availabilityUpdated Mar 6, 2026(via Exa)
How to detect:

When initialize_concurrency_limit_to_default() is called on PostgreSQL and the concurrency key already exists (e.g., due to race condition between concurrent runs or retry after partial failure), the INSERT statement fails with UniqueViolation. PostgreSQL aborts the entire transaction, causing the subsequent UPDATE to fail with InFailedSqlTransaction. This blocks all runs for assets using the pool parameter.

Recommended action:

Immediate workaround: Explicitly set pool limits via Dagster UI, which sets using_default_limit=False and prevents the buggy method from being called. Code fix: In PostgresEventLogStorage, replace INSERT-then-catch-UPDATE pattern with PostgreSQL upsert using INSERT ... ON CONFLICT, or wrap INSERT in conn.begin_nested() SAVEPOINT. Follow pattern used in store_asset_event and add_dynamic_partitions methods.