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