Replikations-Deadlock-Fehler in aktuellen Postgres-Versionen 14-16

Die aktuellen Minor-Releases der Postgres-Versionen 14-16 (14.23, 15.18 und 16.14, veröffentlicht am 14. Mai) haben eine Regression eingeführt, die unter bestimmten Umständen zu einem MultiXactOffsetSLRU Deadlock während der Wiedergabe des Transaktionslogs (WAL) führen kann.

Der Fehler wurde (unseres Wissens nach) erstmals am 20. Mai von Radim Marek von BoringSQL in Bug#19490 gemeldet. Weitere Meldungen erfolgten über die Mailinglisten pgsql-bugs und pgsql-admin, und auch wir erhielten Kunden-Support-Anfragen über unser Open-Source Support Center.

Was derzeit über diesen Fehler bekannt ist

Der Fehler kann auf zwei Arten auftreten. Erstens während der Streaming-Replikation, bei der der Standby aufgrund des Deadlocks schließlich hängt. Die andere Möglichkeit ist ein hängendes Point-in-Time-Recovery (PITR). Folgendes ist derzeit bekannt:

1. Der Fehler tritt nur in den Postgres-Versionen 14-16 auf. Version 17 und 18 (sowie frühere Versionen) sind nicht betroffen.

2. Das WAL muss von einem Leader generiert worden sein, auf dem die Q4/2025-Back-Branch-Releases (13. November) oder älter laufen (14.20/15.15/16.11).

3. Der Standby oder die Instanz, auf der PITR ausgeführt wird, muss auf das neueste Minor-Release (14.23/15.18/16.14) aktualisiert worden sein.

4. Der startup-Prozess hängt während der WAL-Wiedergabe mit dem Wait-Event LWLock/MultiXactOffsetSLRU in pg_stat_activity.

Zusammenfassend lässt sich also sagen, dass der Leader mindestens einige Minor-Versionen zurückliegen muss und der Standby auf die neueste Minor-Version aktualisiert worden sein muss. Aufgrund der empfohlenen Vorgehensweise, zuerst die Streaming-Standbys zu aktualisieren, bevor der Leader aktualisiert wird, tritt dieser Fehler in der Praxis wahrscheinlich relativ häufig auf, insbesondere bei Organisationen, die nur alle paar Minor-Releases patchen.

Umgehung des Problems

Wenn das Problem noch nicht aufgetreten ist, kann es vermieden werden, indem der Standby oder eine PITR-Maschine nicht auf die neuesten Minor-Releases aktualisiert wird. Falls man von der Regression betroffen ist, gibt es drei (nun ja, derzeit zwei) Möglichkeiten, das Problem zu beheben:

1. Ein Downgrade des Standbys oder der PITR-Instanz auf das Q1-Point-Release (oder älter) (14.22/15.17/16.13) behebt das Problem (führt aber möglicherweise zu Problemen, die seitdem behoben wurden).

2. Das Anwenden des Patches „Fix self-deadlock when replaying WAL generated by older minor version“ (Version 16, Version 15, Version 14) vom 27. Mai beim Selbstkompilieren von Postgres und das Starten des Standbys/der PITR-Instanz damit behebt das Problem ebenfalls. Von der Verwendung von Distributionspaketen von PostgreSQL wird generell abgeraten, daher sollte diese Alternative von Organisationen gewählt werden, die PostgreSQL ohnehin immer selbst bauen.

3. Ein Upgrade auf die kommenden Minor-Releases (derzeit für den 13. August geplant) wird das Problem ebenfalls beheben, sobald diese veröffentlicht sind.

Das Problem scheint schwerwiegend genug zu sein, dass man meinen könnte, es rechtfertige ein außerplanmäßiges Back-Branch-Release, was wir vorgeschlagen haben auf der PostgreSQL-Entwicklerliste. Bisher gab es einige andere Personen, die bestätigt haben, dass sie den Fehler gesehen haben (entweder in ihrer eigenen Umgebung oder in den Umgebungen ihrer Kunden), aber es wurde noch keine Entscheidung über ein Release getroffen. Da PostgreSQL 19 Beta 2 derzeit für den 16. Juli geplant ist, erscheint es unwahrscheinlich, dass vorher noch ein weiteres Release eingeschoben werden kann. Nach dem Beta-2-Release bleibt nur noch ein Monat bis zu den nächsten geplanten Minor-Releases. Daher wird für dieses Problem wahrscheinlich kein außerplanmäßiges Release erfolgen und ein Downgrade des Standbys (Option 1 von oben) sollte vorerst gewählt werden.

über den Autor

Michael Banck

zur Person

Michael Banck ist seit 2009 Mitarbeiter der credativ GmbH, sowie seit 2001 Mitglied des Debian Projekts und auch in weiteren Open Source Projekten aktiv. Als Mitglied des Datenbank-Teams von credativ hat er in den letzten Jahren verschiedene Kunden bei der Lösung von Problemen mit und dem täglichen Betrieb von PostgreSQL®, sowie bei der Einführung von Hochverfügbarkeits-Lösungen im Bereich Datenbanken unterstützt und beraten.

Beiträge ansehen