# Postgres-Deadlock-Fehler im n8n-Workflow **URL:** \ **Category:** Questions\ **Tags:** bug:unconfirmed\ **Created:** [4. September 2026 um 08:43 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111 "2026-09-04T08:43:27Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![Kulang](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kulang/32/97213_2.png) [@Kulang](https://community.n8n.io/u/Kulang)\ **Post date:** [4. September 2026 um 08:43 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/1 "2026-09-04T08:43:27Z")
Hallo zusammen, ich habe ein seltsames Problem mit einem meiner n8n-Workflows. Ich verarbeite API-Daten in Batches und führe dann einen Upsert in PostgreSQL durch. Es funktioniert prima, wenn ich eine einzelne Ausführung starte, aber wenn sich mehrere Ausführungen überlappen, erhalte ich manchmal folgende Fehlermeldung: - deadlock detected - SQLSTATE: 40P01 - process 8421 waits for sharelock on transaction 987654; - blocked process by process 7312. Ich verwende auch Redis vor dem Postgres-Node als Lock, aber anscheinend verhindert das nicht das Problem. Hat jemand damit schon Erfahrungen gemacht? Ich bin mir nicht sicher, ob das Problem in meinem n8n-Workflow, beim Batching oder bei der Postgres-Abfrage liegt. ---
**Author:** ![daniel\_Samuel](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/daniel_samuel/32/141401_2.png) [@daniel\_Samuel](https://community.n8n.io/u/daniel_Samuel)\ **Post date:** [4. September 2026 um 08:44 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/2 "2026-09-04T08:44:47Z")
Hi @Kulang kannst du bitte deinen Bildschirm teilen? ---
**Author:** ![Lopez](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/lopez/32/192785_2.png) [@Lopez](https://community.n8n.io/u/Lopez)\ **Post date:** [4. September 2026 um 08:45 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/3 "2026-09-04T08:45:35Z")
Hi @Kulang Willkommen in der Community! 40P01 mit einem ShareLock Wait ist ein Lock-Ordering-Problem, keine Contention, daher kann ein Redis-Lock außerhalb der Datenbank es nicht beheben. Die Upsert-Operation erstellt ein `INSERT ... ON CONFLICT` pro Element und Query Batching setzt standardmäßig Single Query, also wird ein Batch zu vielen Statements in einer Transaktion, und zwei Ausführungen, die dieselben Keys in unterschiedlicher Reihenfolge berühren, führen zu einem Deadlock. 1. Sortiere jeden Batch vor dem Postgres-Knoten nach dem Conflict-Key. Konsistente Lock-Reihenfolge beseitigt die meisten davon sofort. 2. Dedupliziere Keys innerhalb des Batch. 3. Stelle On Error auf Continue, nutze Error Output und wiederhole durch ein kurzes Wait, da ein Deadlock-Opfer sicher zu wiederholen ist. 4. Nur wenn Überlappung inakzeptabel ist, stelle Workflow Concurrency auf 1 statt Koordination in Redis. Wenn es anhält, poste deine Match-On-Spalten und ob Query Batching Single Query oder Transaction ist, sie schlagen unterschiedlich fehl. > **[Postgres | Nodes | n8n Docs](https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.postgres)** > > Learn how to use the Postgres node in n8n. Follow technical documentation to integrate Postgres node into your workflows. ---
**Author:** ![daniel\_Samuel](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/daniel_samuel/32/141401_2.png) [@daniel\_Samuel](https://community.n8n.io/u/daniel_Samuel)\ **Post date:** [4. September 2026 um 08:48 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/4 "2026-09-04T08:48:14Z")
@Kulang Aber dann ist 40p01 ein PostgreSQL-Deadlock. Das passiert normalerweise, wenn zwei Transaktionen versuchen, zusammenhängende Zeilen in unterschiedlicher Reihenfolge zu sperren. Die Redis-Lock ist auch überprüfenswert. Stellen Sie sicher, dass sie wirklich atomar ist und dass jede Ausführung denselben Lock-Key verwendet. Ich würde auch versuchen, die Batch-Größe zu reduzieren und schauen, ob das Problem verschwindet. ---
**Author:** ![daniel\_Samuel](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/daniel_samuel/32/141401_2.png) [@daniel\_Samuel](https://community.n8n.io/u/daniel_Samuel)\ **Post date:** [4. September 2026 um 08:49 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/5 "2026-09-04T08:49:39Z")
@Kulang teile deinen Bildschirm, wenn du fertig bist ---
**Author:** ![Kulang](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kulang/32/97213_2.png) [@Kulang](https://community.n8n.io/u/Kulang)\ **Post date:** [4. September 2026 um 09:09 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/6 "2026-09-04T09:09:28Z")
![screenshot9](https://europe1.discourse-cdn.com/n8n/original/3X/c/8/c84095fb350cd425bf9f20dc53340a153e790632.jpeg) vielen Dank @daniel_Samuel ich habe es überprüft und die Batches können tatsächlich Datensätze desselben Kunden enthalten, also könnte es sein, dass zwei Ausführungen verwandte Zeilen gleichzeitig aktualisieren. Eine Sache, bei der ich mir noch unsicher bin: sollte ich den gesamten Workflow erneut ausführen, wenn dies passiert, oder nur den Postgres-Teil? und wie würdest du das Lock strukturieren? ---
**Author:** ![Lopez](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/lopez/32/192785_2.png) [@Lopez](https://community.n8n.io/u/Lopez)\ **Post date:** [4. September 2026 um 09:11 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/7 "2026-09-04T09:11:51Z")
Nur den Postgres-Knoten. Die Transaktion des Opfers wird vollständig zurückgerollt, daher muss nichts vorgelagert werden und das erneute Ausführen des Workflows würde die API für einen fehlgeschlagenen Batch erneut abrufen. Aktivieren Sie dort „Retry On Fail ---
**Author:** ![daniel\_Samuel](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/daniel_samuel/32/141401_2.png) [@daniel\_Samuel](https://community.n8n.io/u/daniel_Samuel)\ **Post date:** [4. September 2026 um 09:15 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/8 "2026-09-04T09:15:50Z")
@Kulang Ich würde den gesamten Workflow nicht wiederholen, du kannst es tun, wenn du möchtest … Ich würde die Postgres-Operation in einen separaten Sub-Workflow auslagern und nur diesen Teil wiederholen. Für Redis verwende einen atomaren Lock mit einer TTL, anstatt einfach zu prüfen, ob ein Schlüssel existiert, und ihn dann zu setzen. Etwa nach folgendem Schema Acquire Redis Lock =\> Postgres Upsert =\> Release Lock Bei 40P01 verwende einen kurzen exponentiellen Backoff, bevor du einen Retry durchführst ---
**Author:** ![catchleak](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/catchleak/32/186360_2.png) [@catchleak](https://community.n8n.io/u/catchleak)\ **Post date:** [6. September 2026 um 10:10 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/9 "2026-09-06T10:10:52Z")
Es gibt etwas, das bisher niemand gesagt hat, und das ist genau der Punkt, der uns getroffen hat: Die Lösung, auf die du hinarbeitest, kann einen lauten Fehler in einen stillen verwandeln. „Retry On Fail ---
**Author:** ![Kulang](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kulang/32/97213_2.png) [@Kulang](https://community.n8n.io/u/Kulang)\ **Post date:** [7. September 2026 um 09:36 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/10 "2026-09-07T09:36:04Z")
@daniel_Samuel ich habe den Workflow wie du vorgeschlagen hast geändert. Ich habe den Postgres-Teil in einen separaten Sub-Workflow verschoben und den Redis-Schritt geändert, um SET NX mit einem Ablaufdatum zu verwenden. Der Deadlock-Fehler tritt jetzt viel seltener auf, aber ich habe etwas Seltsames bemerkt. Wenn zwei Ausführungen fast gleichzeitig starten, erhält eine den Redis-Lock und die andere erhält: SET NX -false Aber die zweite Ausführung scheint nicht zu warten. Sie setzt sich trotzdem zum Postgres-Node fort. Ich sehe manchmal auch zwei Ausführungen, die fast exakt gleichzeitig denselben Kunden aktualisieren. Missverstehe ich, wie SET NX funktionieren soll? ---
**Author:** ![Kulang](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kulang/32/97213_2.png) [@Kulang](https://community.n8n.io/u/Kulang)\ **Post date:** [7. September 2026 um 09:36 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/11 "2026-09-07T09:36:51Z")
Hmm, das ist interessant, danke. ---
**Author:** ![daniel\_Samuel](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/daniel_samuel/32/141401_2.png) [@daniel\_Samuel](https://community.n8n.io/u/daniel_Samuel)\ **Post date:** [7. September 2026 um 09:41 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/12 "2026-09-07T09:41:12Z")
SET NX gibt false zurück, wenn der Schlüssel bereits existiert, sodass die Ausführung die Sperre nicht erworben hat. Ich würde eine IF/Switch nach dem Redis-Knoten einfügen und nur dann zu Postgres weitergehen, wenn die Sperre erfolgreich erworben wurde. Für den false-Branch könntest du einen Wait-Knoten hinzufügen und es erneut versuchen. Achte auch darauf, dass die Sperre ein TTL hat, damit abgestürzte Ausführungen sie nicht blockieren. ---
**Author:** ![Kulang](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kulang/32/97213_2.png) [@Kulang](https://community.n8n.io/u/Kulang)\ **Post date:** [7. September 2026 um 09:43 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/13 "2026-09-07T09:43:08Z")
Danke dafür ---
**Author:** ![system](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/system/32/195824_2.png) [@system](https://community.n8n.io/u/system)\ **Post date:** [14. September 2026 um 09:43 UTC](https://community.n8n.io/t/postgres-deadlock-error-in-n8n-workflow/311111/14 "2026-09-14T09:43:13Z")
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.