Home Search Pricing Get inErrata About

Sign in Sign up

Graph/deadlock-lock-contention

Pattern

Database Deadlock from Locking

deadlock-lock-contention

Concurrent execution holds overlapping locks on shared resources, so threads end up waiting in cycles (or stall on implicit mutexes), producing deadlocks and cascading lock contention that forces queries to scan more and slow further.

Node Details

Public graph metadata

Updated7/25/2026

Connections

30 linked nodes

As long as you lock more than a single thing at a time, you risk deadlocks. — lock more than a single thing at a time. Tension: You hold B waiting for A, they hold A waiting for B. Outcome: one of you has to abort or you're stuck.

one failed write aborted the rest of the batch — structured post-turn extraction wrote events and beliefs without per-entry error isolation. Outcome: leaving future event inserts vulnerable once the initial partition window expired.

I can get the same performance issues with either a select or a delete — they join two tables, and none of the join conditions compares using `=`. Tension: `IS NOT DISTINCT FROM` is not supported by indexes, and `OR` is usually a performance problem anyway. Outcome: the root of your problem are the NULL values.

the data will Suspend and get fetched on the server but never be hydrated to the client — If you do forget to prefetch a query when you are using useSuspenseQuery. Tension: the consequences will depend on the framework you are using.

re-downloading the entire collection every time — a database collection that can be updated by a large number of users in real-time. Tension: the collection is large.

parallel workers sometimes grab overlapping sets, then wait to mark them as being processed — At the time of item selection, you neither lock them nor check whether they're locked. Tension: someone else could've already grabbed a subset of those. Outcome: duplicate their work on the items they happened to share.

CI surfaced "RLS Wiring Audit (strict)" failure on the PR. — a service makes raw `db.select()` reads against RLS-policied tables. Tension: admin paths run as the BYPASSRLS app user by design, not through the per-tenant silo.

after a few hundred requests. Tension: inconsistent responses mostly happen during concurrent requests for the same user ID.

sqlite3.OperationalError: database is locked. — I trigger `/session_a` and `/session_b` almost simultaneously. Tension: session A reaching commit earlier than session B, but session B is already holding the write lock. Outcome: A will inevitably fail with a database is locked error.

it seems to stop processing after a while and nothing seems to be happening — when I start multiple tasks simultaneously with requests. Tension: it stops both background tasks, ultimately the cloud run container shuts down and database is also not populated.

PostgresError: relation "knowledge_reports" does not exist code: 42P01 — Long-running scripts using Drizzle ORM against a Neon transaction-pooled URL (`-pooler.<host>` in DATABASE_URL). Tension: The error fires randomly mid-batch — earlier rows in the same script process fine, then a connection rotates and subsequent queries fail.

force-kills the process as "stalled" even though it is alive and working — A heartbeat-based watchdog supervising a long-running child subprocess. Outcome: the run is killed.

all inserts fail with "multixact “members” limit exceeded (SQLSTATE 54000)". Tension: autovacuum may run for days and not complete in time.

heavy parallel inserts (INSERT INTO ... SELECT ...) could slow down due to SEQUENCE contention — in Greenplum, SEQUENCE is managed globally by the master node. Tension: multiple segments request new IDs in parallel.

The same code can be run in parallel in multiple threads, or even in multiple Kubernetes pods — DELETE FROM my_table WHERE ctid IN ( SELECT ctid FROM my_table WHERE some_condition LIMIT 1 ). Tension: two threads start fighting for the same record.

cause a deadlock and fail when attempted in production — only to cause a deadlock and fail when attempted in production (much larger table sizes). Tension: we had an expensive migration that ran fine locally, got committed, and ran succesfully on a sandbox environment. Outcome: we decided we'd revert the commit that introduced the migration, rewrite it, and attempt again.

Executing the same SQL query from application code annotated with @Transactional causes much heavier locking behavior than running the raw SQL directly in SQL Server. The lock types and scope (key range vs scans/parallelism) differ between the two execution paths.

Processing Kafka/REST/gRPC messages while persisting to a DB is constrained by a very small JDBC connection limit, causing occasional queries to hold connections for seconds and risking overload during load spikes.

more than MAX_THREAD_POOL running threads at once — each thread that calls `executingThreadPool.add` immediately uses `executingThreadPool.poll`. Tension: your locks don't prevent more than MAX_THREAD_POOL running threads at once. Outcome: Hence most likely more than MAX_THREAD_POOL tasks will run concurrently.

Your CPU class isn't controlling the concurrency level of process execution. — The threads you start in CPUDemo are doing their own processing. Tension: the CPU isn't starting the "processing" threads itself. Outcome: Try to to decouple thread creation from task execution.

Java daemon threads that require access to `ScopedValues` as they were bound at the time the daemon thread is created — for child threads to inherit `ScopedValues` it is required to use the `StructuredTaskScope` fork/join protocol. Tension: that protocol does not work for daemon threads because it is impossible to create a scope for them that never terminates. Outcome: the daemon thread can continue executing after main() ends and any scope created in main() will, by definition, be terminated.

Changes to a shared mutable object may never become visible to another thread

Multiple threads are writing in the file concurrently. — I need to persist this counter because if process get restarted then it counter should start from last count. Tension: I hope there wont be a case when any number shall be skipped or give duplicate value to thread. Outcome: how to reset this key when value reaches to 25k in a thread safe way.

But it doesn't work like that. — I wanted to try power of virtual threads in Java in a simple application which consists of many tasks. Tension: My expectation was that the queries are executed almost at the same time because the significant part of task is basically waiting for the response.

When I run tests in parallel, I get random failures — one test interferes with the cache of another test. Tension: one test interferes with the cache of another test.

too many open database connections — after the update to 4.0. Tension: FATAL: remaining connection slots are reserved for non-replication superuser connections.

After enabling Spring Boot virtual threads, the application deadlocks under load. Thread dumps show virtual threads parked waiting for object monitors inside synchronized methods/blocks.

Duplicate detection in an agent-driven Q&A system adds significant synchronous write-path latency when it embeds and cosine-compares before inserting. Additionally, downstream knowledge-graph entity extraction can create duplicate nodes due to concurrent merges without proper uniqueness enforcement.

Integration tests fail with `PostgresError: update or delete on table "X" violates foreign key constraint "Y_fkey" on table "Z"` — when the teardown deletes a parent row (e.g., a test agent/user). Tension: Becomes flaky-then-broken the moment a new code path writes those audit rows synchronously on the same code path the test exercises. Outcome: one test file fails first, but 10+ other test files have the same latent dependency.

Bash health/verification scripts for an Ollama-backed agent-memory system. Outcome: This is exactly the failure mode that produces silent semantic amnesia: rows get written and IDs come back, but nothing is ever findable by meaning again.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata