pg_probackup не накатывает wal до конца

[stevemayster]

Добрый день.
Пытаемся понять причину такого поведения:
База восстанавливается нормально но wal до конца не докатывает, останавливается и чего-то ждет:

В логах БД

2026-07-07 10:46:07 MSK [35489]: [1-1]: INFO: pg_probackup archive-get WAL file: 0000000500000B4D0000009C, remote: ssh, threads: 1/1, batch: 1
2026-07-07 10:46:07 MSK [35489]: [1-1]: INFO: pg_probackup archive-get completed successfully, fetched: 1/1, time elapsed: 420ms
2026-07-07 10:46:07.627 MSK [35246] LOG:  restored log file "0000000500000B4D0000009C" from archive
2026-07-07 10:46:07.634 MSK [35246] LOG:  redo in progress, elapsed time: 20.26 s, current LSN: B4D/9BFE4750
2026-07-07 10:46:07 MSK [35497]: [1-1]: INFO: pg_probackup archive-get WAL file: 0000000500000B4D0000009D, remote: ssh, threads: 1/1, batch: 1
2026-07-07 10:46:08 MSK [35497]: [1-1]: INFO: pg_probackup archive-get completed successfully, fetched: 1/1, time elapsed: 387ms
2026-07-07 10:46:08.042 MSK [35246] LOG:  restored log file "0000000500000B4D0000009D" from archive
2026-07-07 10:46:08 MSK [35499]: [1-1]: INFO: pg_probackup archive-get WAL file: 0000000500000B4D0000009E, remote: ssh, threads: 1/1, batch: 1
2026-07-07 10:46:08 MSK [35499]: [1-1]: INFO: pg_probackup archive-get completed successfully, fetched: 1/1, time elapsed: 390ms
2026-07-07 10:46:08.463 MSK [35246] LOG:  restored log file "0000000500000B4D0000009E" from archive
2026-07-07 10:46:08 MSK [35501]: [1-1]: INFO: pg_probackup archive-get WAL file: 0000000500000B4D0000009F, remote: ssh, threads: 1/1, batch: 1
2026-07-07 10:46:08 MSK [35501]: [1-1]: INFO: pg_probackup archive-get completed successfully, fetched: 1/1, time elapsed: 433ms
2026-07-07 10:46:08.926 MSK [35246] LOG:  restored log file "0000000500000B4D0000009F" from archive
2026-07-07 10:46:08 MSK [35509]: [1-1]: INFO: pg_probackup archive-get WAL file: 0000000500000B4D000000A0, remote: ssh, threads: 1/1, batch: 1
2026-07-07 10:46:09 MSK [35509]: [1-1]: INFO: pg_probackup archive-get completed successfully, fetched: 1/1, time elapsed: 392ms
2026-07-07 10:46:09.347 MSK [35246] LOG:  restored log file "0000000500000B4D000000A0" from archive
2026-07-07 10:46:09 MSK [35511]: [1-1]: INFO: pg_probackup archive-get WAL file: 0000000500000B4D000000A1, remote: ssh, threads: 1/1, batch: 1
2026-07-07 10:46:09 MSK [35511]: [1-1]: INFO: pg_probackup archive-get completed successfully, fetched: 1/1, time elapsed: 407ms
2026-07-07 10:46:09.785 MSK [35246] LOG:  restored log file "0000000500000B4D000000A1" from archive
2026-07-07 10:46:09 MSK [35519]: [1-1]: INFO: pg_probackup archive-get WAL file: 0000000500000B4D000000A2, remote: ssh, threads: 1/1, batch: 1
2026-07-07 10:46:10 MSK [35519]: [1-1]: INFO: pg_probackup archive-get completed successfully, fetched: 1/1, time elapsed: 431ms
2026-07-07 10:46:10.246 MSK [35246] LOG:  restored log file "0000000500000B4D000000A2" from archive
2026-07-07 10:46:10 MSK [35521]: [1-1]: INFO: pg_probackup archive-get WAL file: 0000000500000B4D000000A3, remote: ssh, threads: 1/1, batch: 1
2026-07-07 10:46:10 MSK [35521]: [1-1]: INFO: pg_probackup archive-get completed successfully, fetched: 1/1, time elapsed: 395ms
2026-07-07 10:46:10.672 MSK [35246] LOG:  restored log file "0000000500000B4D000000A3" from archive```

Что попробовали на данный момент:
1)  Стянули вол руками в папку и перезапустили базу pkill, накат остановился на том-же wal и дальше не идет
2) Проверить следующий wal pg_waldump - он валиден
3) Стянуть  файлик через pg_probackup archive-fetch ( все в порядке)

В настройках postgresql.auto.conf  стоит следующее и для всех остальных баз кроме этой работает

# recovery settings added by pg_probackup restore of backup THRP8P at '2026-07-07 10:21:15+03'
## recovery settings
recovery_target_timeline = 'current'
recovery_target_action = 'pause'
restore_command = '"/usr/bin/pg_probackup-16" archive-get -B "/backups" --instance "db" --wal-file-path=%p --wal-file-name=%f --remote-host=srv-bkp-2 --remote-user=rman'

И на всех БД кроме этой работает

Нашли workaround пока такой:

Запустить с recovery-target = immediate

База запускается в RO и просит выполнить pg_wal_replay_resume() 
Затем фетчит один wal и запускается в RW

[fukanchik]

Добрый день,
wal до конца не докатывает, останавливается и чего-то ждет:

не очень понятно, что именно Вы имеете в виду, но очень похоже на
https://postgrespro.ru/docs/postgrespro/18/runtime-config-wal#GUC-RECOVERY-TARGET-ACTION

в документации пробэкапа это описано вот так:

--recovery-target-action=pause|promote|shutdown

    Задаёт действие ([recovery_target_action](https://postgrespro.ru/docs/postgrespro/18/runtime-config-wal#GUC-RECOVERY-TARGET-ACTION)), которое должен выполнить сервер по достижении цели восстановления.

    По умолчанию: pause

[stevemayster]

@fukanchik Добрый день.
Мы ожидаем что БД накатит все необходимые ей WAL и перейдет в RW ( так происходит на других базах с аналогичными настройками)

wal до конца не докатывает, останавливается и чего-то ждет: я имел в виду что WAL на бекапном сервере еще есть но дальше они не подтягиваются, БД не находится в паузе, она просто висит, к ней нельзя подключиться или перезапустить её

Дополню что мы на этом же сервере БД с теми-же настройками раскатывали бекап от других БД и он раскатывался без проблем

[stevemayster]

@fukanchik Добрый день.
Мы продолжили эксперименты и решили откатить версию Postgres с 16.14 до 16.13
На этой версии восстановление прошло успешно, на применении wal на котором останавливалось ранее сейчас в логах БД такая запись:

026-07-08 09:16:05.610 MSK [11149] LOG:  restored log file "0000000500000B540000005A" from archive
2026-07-08 09:16:05.617 MSK [11149] DEBUG:  got WAL segment from archive
2026-07-08 09:16:05.630 MSK [11149] DEBUG:  next offsets page is not initialized, initializing it now
2026-07-08 09:16:05.630 MSK [11149] CONTEXT:  WAL redo at B54/5A30AA28 for MultiXact/CREATE_ID: 32571391 offset 65963935 nmembers 2: 821758745 (keysh) 821758747 (keysh)
2026-07-08 09:16:05.635 MSK [11149] DEBUG:  skipping initialization of offsets page 15904 because it was already initialized on multixid creation
2026-07-08 09:16:05.635 MSK [11149] CONTEXT:  WAL redo at B54/5A413258 for MultiXact/ZERO_OFF_PAGE: 15904

Видимо мы попали на этот баг:

Replication Deadlock Bug in Current Postgres Releases 14-16
A regression introduced in PostgreSQL minor releases 14.23, 15.18, and 16.14 (released May 14th) can cause a MultiXactOffsetSLRU deadlock during WAL replay, hanging streaming replication standbys or PITR instances. The bug is triggered when the primary runs an older minor release (Q4/2025 or earlier) while the standby is updated to the latest minor version — a common scenario given the recommended practice of updating standbys first. PostgreSQL 17 and 18 are unaffected. Workarounds include downgrading the standby to 14.22/15.17/16.13, applying the specific upstream patch if self-compiling, or waiting for the next scheduled minor releases targeted for August 13th. An out-of-band emergency release has been proposed but appears unlikely before the scheduled August releases.