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 des Nachspielens 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 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 vier (derzeit drei) 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. Ein zweistufiges Upgrade-Verfahren, bei dem zunächst die Standbys und dann der Leader auf die Q1-Point-Releases aktualisiert werden (siehe vorherige Option), gefolgt von einem zweiten Upgrade der Standbys (und dann schließlich des Leaders) auf die neuesten Point-Releases. Dadurch wird das Problem umgangen, da der Leader dann auf einer sicheren Version läuft, die keine problematischen WAL-Records erzeugt, die auf den Standbys zu dem Deadlock führen.

3. 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 Nicht-Verwendung von Distributionspaketen von PostgreSQL wird generell abgeraten, daher sollte diese Alternative nur von Organisationen gewählt werden, die PostgreSQL ohnehin immer selbst bauen.

4. 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 sollte ein außerplanmäßiges Back-Branch-Release rechtfertigen, was wir auf der PostgreSQL-Development-Liste vorgeschlagen haben. Bisher haben ein paar andere Leute bestätigt, dass sie den Bug gesehen haben (entweder in ihrer eigenen Umgebung oder in den Umgebungen ihrer Kunden), aber eine Entscheidung über ein Release wurde noch nicht getroffen. Da PostgreSQL 19 Beta 2 derzeit für den 16. Juli geplant ist, erscheint es unwahrscheinlich, dass davor noch ein weiteres Release eingeschoben werden könnte. 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 vorerst sollte ein Downgrade des Standbys (Option 1 von oben) oder ein zweistufiges Upgrade-Verfahren (Option 2 von oben) 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