It's looking for a checkpoint record in the transaction log that probably doesn't exist or is corrupted. You can determine if this is the case by running:
# Postgres >= 10
pg_resetwal DATADIR
# Postgres < 10
pg_resetxlog DATADIR
If the transaction log is corrupt, you'll see a message like:
The database server was not shut down cleanly. Resetting the
transaction log might cause data to be lost. If you want to proceed
anyway, use -f
to force reset.
You can then follow the instructions and run with -f
to force the update:
# Postgres >= 10
pg_resetwal -f DATADIR
# Postgres < 10
pg_resetxlog -f DATADIR
That should reset the transaction log, however it could leave your database in an indeterminate state as explained in the PostgreSQL documentation on pg_resetwal
:
If pg_resetwal
complains that it cannot determine valid data for
pg_control
, you can force it to proceed anyway by specifying the
-f
(force) option. In this case plausible values will be substituted
for the missing data. Most of the fields can be expected to match, but
manual assistance might be needed for the next OID, next transaction
ID and epoch, next multitransaction ID and offset, and WAL starting
location fields. These fields can be set using the options discussed
below. If you are not able to determine correct values for all these
fields, -f
can still be used, but the recovered database must be
treated with even more suspicion than usual: an immediate dump and
reload is imperative. Do not execute any data-modifying operations in
the database before you dump, as any such action is likely to make the
corruption worse.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…