Replication Deadlock Bug in Current Postgres Releases 14-16

The current minor releases of Postgres versions 14-16 (14.23, 15.18 and 16.14, released on May 14th) introduced a regression that can lead to a MultiXactOffsetSLRU deadlock during transaction log (WAL) replay in certain circumstances.

The bug was (to our knowledge) first reported in Bug#19490 on May 20th by Radim Marek from BoringSQL. Further reports were done on the pgsql-bugs and pgsql-admin mailing lists and we also got customer support requests through our Open-Source Support Center.

What is Currently Known About This Bug

The bug can be hit in two ways. First, during streaming replication where the standby eventually hangs due to the deadlock. The other possibility is hanging point-in-time-recovery (PITR). The following is currently known:

1. The bug is only live on Postgres versions 14-16. Version 17 and 18 (and earlier versions) are not affected.

2. The WAL needs to be generated by a leader running the Q4/2025 (November 13th) back-branch releases or earlier (14.20/15.15/16.11).

3. The standby or the instance running PITR needs to be updated to the latest minor release (14.23/15.18/16.14).

4. The startup process hangs with wait event LWLock/MultiXactOffsetSLRU in pg_stat_activity during WAL replay.

So to summarize, the leader needs to be at least a few minor versions behind and the standby needs to be updated to the latest minor version. Due to the recommended procedure of updating streaming standbys first before updating the leader, this bug is likely to be hit relatively often in the field, especially by organizations that only patch every few minor releases.

Circumventing the Issue

If one has not yet hit the issue, then not upgrading the standby or a PITR machine to the latest minor releases will avoid the problem. In the case that one is affected by the regression, there are three (well, currently two) ways to address the problem:

1. Downgrading the standby or the PITR instance to the Q1 (or earlier) point release (14.22/15.17/16.13) fixes the problem (but will potentially re-introduce problems fixed since).

2. Applying the patch “Fix self-deadlock when replaying WAL generated by older minor version” (version 16, version 15, version 14) from May 27th when self-compiling Postgres and starting the standby/PITR-instance with this also fixes the problem. Not using distribution packages of PostgreSQL is generally not advised, so this alternative should be chosen by organizations that always build PostgreSQL themselves anyway.

3. Upgrading to the upcoming minor releases (currently targeted for August 13th) will also fix the problem, once they are released.

The problem seems severe enough that one might think it should warrant an out-of-band back-branch release, which is what we have suggested on the PostgreSQL development list. So far, there have been a few other people confirming that they saw the bug (either in their own environment, or the environments of their customers), but no decision on a release has been made. As PostgreSQL 19 Beta 2 is currently scheduled for July 16th, it looks unlikely that another release could be squeezed in before. After the Beta 2 release, there is only one month left until the next scheduled minor releases. So probably no out-of-band release will be done for this issue and a downgrade of the standby (option 1 from above) should be chosen for the time being.

About the author

Michael Banck

about the person

Michael Banck has been an employee of credativ GmbH since 2009, a member of the Debian project since 2001, and is also active in other open-source projects. As a member of the database team at credativ, he has supported and advised various customers in recent years on solving problems with and the daily operation of PostgreSQL®, as well as on the introduction of high-availability solutions in the database sector.

View posts