Он ищет запись контрольной точки в журнале транзакций, которая, вероятно, не существует или повреждена. Вы можете определить, так ли это, запустив:
# Postgres < 10.0
pg_resetxlog DATADIR
# Postgres >= 10.0
pg_resetwal DATADIR
Если журнал транзакций поврежден, вы увидите сообщение вроде:
Сервер базы данных не был корректно выключен. Сброс
журнал транзакций может привести к потере данных. Если вы хотите продолжить
в любом случае, используйте -f для принудительного сброса.
Затем вы можете следовать инструкциям и запустить с -f для принудительного обновления:
# Postgres < 10.0
pg_resetxlog -f DATADIR
# Postgres >= 10.0
pg_resetwal -f DATADIR
Это должно сбросить журнал транзакций, однако это может привести к тому, что ваша база данных останется в неопределенном состоянии, как объяснено в документации PostgreSQL о
pg_resetxlog
Если pg_resetxlog жалуется на то, что он не может определить действительные данные для pg_control, вы можете принудительно продолжить его, указав переключатель -f (force). В этом случае вероятные значения будут заменены отсутствующими данными. Можно ожидать совпадения большинства полей, но может потребоваться ручная помощь для следующего OID, следующего идентификатора транзакции и периода, следующего идентификатора многотранзакции и смещения и полей начального адреса WAL. Эти поля могут быть установлены с помощью переключателей, обсуждаемых ниже. Если вы не можете определить правильные значения для всех этих полей, -f все еще можно использовать, но к восстановленной базе данных следует относиться с еще большим подозрением, чем обычно: немедленный сброс и перезагрузка являются обязательными. Не выполняйте никакие операции по изменению данных в базе данных, прежде чем создавать дамп, так как любое такое действие может усугубить повреждение.