MIME-Version: 1.0
References: <19490-9c59c6a583513b99@postgresql.org>
 <46FE61C9-F273-45FD-BED7-0F8CDA6EB992@yandex-team.ru>
In-Reply-To: <46FE61C9-F273-45FD-BED7-0F8CDA6EB992@yandex-team.ru>
From: Marko Tiikkaja <marko@joh.to>
Date: Thu, 21 May 2026 10:12:08 +0300
Message-ID: 
 <CAL9smLBMxKBCmsA9UGcmf93bT2_MsZ+POH-oHREuwKdmMU7jfQ@mail.gmail.com>
Subject: Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on
 MultiXactOffsetSLRU when primary is 16.8
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: radim@boringsql.com,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAL9smLBMxKBCmsA9UGcmf93bT2_MsZ%2BPOH-oHREuwKdmMU7jfQ%40mail.gmail.com>
Precedence: bulk

Hi Andrey,

On Thu, May 21, 2026 at 10:07=E2=80=AFAM Andrey Borodin <x4mmm@yandex-team.=
ru> wrote:
> Are you sure that it's not 16.11 that is resolving the problem?
> Can you get a backtrace of hanging startup process with debug symbols?

We had this problem just morning:

#0  __futex_abstimed_wait_common64 (private=3D<optimized out>,
cancel=3Dtrue, abstime=3D0x0, op=3D265, expected=3D0,
futex_word=3D0x785c290170b8) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=3Dtrue, private=3D<optimized
out>, abstime=3D0x0, clockid=3D0, expected=3D0, futex_word=3D0x785c290170b8=
)
at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64
(futex_word=3Dfutex_word@entry=3D0x785c290170b8,
expected=3Dexpected@entry=3D0, clockid=3Dclockid@entry=3D0,
abstime=3Dabstime@entry=3D0x0,
    private=3D<optimized out>) at ./nptl/futex-internal.c:139
#3  0x0000786048c9cbdf in do_futex_wait (sem=3Dsem@entry=3D0x785c290170b8,
abstime=3D0x0, clockid=3D0) at ./nptl/sem_waitcommon.c:111
#4  0x0000786048c9cc78 in __new_sem_wait_slow64
(sem=3Dsem@entry=3D0x785c290170b8, abstime=3D0x0, clockid=3D0) at
./nptl/sem_waitcommon.c:183
#5  0x0000786048c9ccf1 in __new_sem_wait
(sem=3Dsem@entry=3D0x785c290170b8) at ./nptl/sem_wait.c:42
#6  0x0000654c8b150b86 in PGSemaphoreLock (sema=3D0x785c290170b8) at
port/pg_sema.c:327
#7  LWLockAcquire (lock=3D0x785c29017a80, mode=3DLW_EXCLUSIVE) at
storage/lmgr/./build/../src/backend/storage/lmgr/lwlock.c:1314
#8  0x0000654c8ae2acba in SimpleLruWriteAll (ctl=3D0x654c8b63e400
<MultiXactOffsetCtlData.lto_priv.0>, allow_redirtied=3D<optimized out>)
    at access/transam/./build/../src/backend/access/transam/slru.c:1174
#9  0x0000654c8ae22719 in RecordNewMultiXact (multi=3D1201227775,
offset=3D2755202388, nmembers=3D2, members=3D0x7860465ec28c)
    at access/transam/./build/../src/backend/access/transam/multixact.c:944
#10 0x0000654c8ae255c6 in multixact_redo (record=3D0x654cb292c620) at
access/transam/./build/../src/backend/access/transam/multixact.c:3464
#11 0x0000654c8ae4ea2d in ApplyWalRecord (replayTLI=3D<synthetic
pointer>, record=3D0x7860465ec250, xlogreader=3D<optimized out>)
    at access/transam/./build/../src/include/access/xlog_internal.h:379
#12 PerformWalRecovery () at
access/transam/./build/../src/backend/access/transam/xlogrecovery.c:1782
#13 0x0000654c8ae3bcb7 in StartupXLOG () at
access/transam/./build/../src/backend/access/transam/xlog.c:5452
#14 0x0000654c8b0cbe7b in StartupProcessMain () at
postmaster/./build/../src/backend/postmaster/startup.c:282

We downgraded to 16.13 and the problem went away.


.m