nins3) запуск БД
Никак.
Более того учтите, что у вас и сейчас данные непонятно какие, а не суточной давности. Потому что именно это resetwal и предназначен делать. Тем более в -f режиме. Цитируя core разработчика postgresql:
Michael PaquierIt is so easy to screw things up with pg_resetwal that we ought to rename it pg_please_corrupt_my_data.

ninsвот это поможет?

24.3. Непрерывное архивирование и восстановление на момент времени (Point-in-Time Recovery, PITR)
Поможет. Если у вас есть basebackup от некоторого момента в прошлом + все WAL от начала снятия basebackup до необходимого места восстановления. Повреждённый datadir после аварии для этого не годится.

Бекапы вещь такая, о которой надо заботиться заранее.

ninsСитуация, когда сбрасывался журнал на нечто не существующее - ее просто нет.
Есть. После pg_resetwal в datadir неконсистентная каша гарантирована. Именно это и предназначен делать pg_resetwal. Непойми что в данных, но как-то запустить и попытаться вытащить хоть что-нибудь и руками потом разбираться, что из этого имеет смысл.
Неудачное название утилиты получилось. Надо было называть pg_please_corrupt_my_data. Уж сколько всего люди сломали отчего полагая, что это какая-то магия, а не прямая инструкция сломать весь кластер.

ninspg_resetwal сбросил журнал предзаписи
на более древний, зафиксированный и существовавший момент времени
И сломали транзакционную видимость до невосстановимого состояния.
Это by design. resetwal прямым текстом обещает в мануале, что после его выполнения вы не получите консистентного состояния.
Эту утилиту можно выполнять только и исключительно имея копию datadir. И, конечно, с полным пониманием что это такое, что произойдёт и как это отразится на механике работы СУБД.