Il recherche un enregistrement de point de contrôle dans le journal des transactions qui n'existe probablement pas ou qui est corrompu. Vous pouvez déterminer si c'est le cas en exécutant :
# Postgres >= 10
pg_resetwal DATADIR
# Postgres < 10
pg_resetxlog DATADIR
Si le journal des transactions est corrompu, vous verrez un message comme :
Le serveur de base de données n'a pas été arrêté proprement. La réinitialisation du journal des transactions peut entraîner la perte de données. Si vous voulez continuer quand même, utilisez
-fpour forcer la réinitialisation.
Vous pouvez ensuite suivre les instructions et exécuter avec -f pour forcer la mise à jour :
# Postgres >= 10
pg_resetwal -f DATADIR
# Postgres < 10
pg_resetxlog -f DATADIR
Cela devrait réinitialiser le journal des transactions, mais cela pourrait laisser votre base de données dans un état indéterminé comme expliqué dans la documentation PostgreSQL sur pg_resetwal :
Si
pg_resetwalse plaint qu'il ne peut pas déterminer les données valides pourpg_control, vous pouvez le forcer à continuer quand même en spécifiant le-f(forcer). Dans ce cas, des valeurs plausibles seront substituées aux données manquantes. On peut s'attendre à ce que la plupart des champs correspondent, mais une assistance manuelle peut être nécessaire pour l'OID suivant, l'ID de transaction et l'époque suivants, l'ID et l'offset multitransaction suivants et les champs d'emplacement de départ WAL. Ces champs peuvent être définis à l'aide des options décrites ci-dessous. Si vous n'êtes pas en mesure de déterminer les valeurs correctes pour tous ces champs,-fpeut toujours être utilisé, mais la base de données récupérée doit être traitée avec encore plus de méfiance que d'habitude :un vidage et un rechargement immédiats sont impératifs. N'exécutez aucune opération de modification des données dans la base de données avant le vidage, car une telle action est susceptible d'aggraver la corruption.
