'postgresql error PANIC: could not locate a valid checkpoint record
When I load up the postgres server (v9.0.1) i get a panic that prevents it from starting:
PANIC: could not locate a valid checkpoint record
How can I fix this?
Solution 1:[1]
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_resetwalcomplains that it cannot determine valid data forpg_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,-fcan 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.
Solution 2:[2]
I'm running 9.1.7 and i find ran the following successfully:
/usr/lib/postgresql/9.1/bin/pg_resetxlog -f /var/lib/postgresql/9.1/main
Your final argument to the pg_resetxlog command should be the location on disk where postgres stores your database data.
Solution 3:[3]
As indicated here pg_resetxlog should not be run. The answers that refer to this is bad advice. Assuming the error occured in a context of copy/replication instance, the link provides a more succinct way of doing copy/replication with pg_basebackup
Solution 4:[4]
Do you do continuous archiving? If you are backing up at the time, you may find it more prudent to remove backup_label. pg_resetxlog is a severe thing.
Solution 5:[5]
I came across here with a Docker Postgresql-13 which did not start again. I fixed it by finding the volume (for the data) and running
Being in the volume data folder, e.g., /var/lib/docker/volumes/c4c8d637d9eee086265d732b2974690b731abcb23f47ca61bf75fe28526e31ce/_data
run as owner of the directory (for me it was the systemd-coredump user)
sudo -u systemd-coredump /usr/lib/postgresql/13/bin/pg_resetwal -f .
For sure you need the same Postgresql version installed (if the pg_resetwal is not part of the volume)
worked
Solution 6:[6]
just like the log saying : could not locate a valid checkpoint record.Postgres can't find a properly WAL under the $PGDATA/pg_xlog/ directory. Try to use pg_resetxlog
Solution 7:[7]
For me it worked when i removed the folder with data from postgres, so it was near other solutions but anyone explained that deleting the folder could sove.
SO: Ubuntu 20.04
Step by step:
- docker-compose down
- docker rmi $(docker images -q)
- Only on ubuntu or debian based: cd ~ && sudo rm -r postgres docker-compose up
Solution 8:[8]
This answer is for Postgres 14. I was getting the same error in the standby logs after the following steps:
- Login to stand-by.
- Create back up with the below command:
pg_basebackup -D $APP_BACKUP_PATH -F t -P -v -U replicator -w --no-password -h 10.29.51.98
Extract generated
$APP_BACKUP_PATH/base.tarto standby data directory.Restart the standby. The start up fails with :
PANIC: could not locate a valid checkpoint record.So, it turns out that the backup was not generated right. It needs to be generated with an additional option
-X stream.After regenerating and applying the updated back up to the stand by data directory, the stand-by came up without this error.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | |
| Solution 2 | Matthias Robbers |
| Solution 3 | Community |
| Solution 4 | fdr |
| Solution 5 | tuergeist |
| Solution 6 | sgzhan |
| Solution 7 | Gabriel Silva |
| Solution 8 | Binita Bharati |
