Het zoekt naar een controlepuntrecord in het transactielogboek dat waarschijnlijk niet bestaat of beschadigd is. U kunt bepalen of dit het geval is door het volgende uit te voeren:
# Postgres >= 10
pg_resetwal DATADIR
# Postgres < 10
pg_resetxlog DATADIR
Als het transactielogboek beschadigd is, ziet u een bericht als:
De databaseserver is niet netjes afgesloten. Als u het transactielogboek opnieuw instelt, kunnen er gegevens verloren gaan. Als je toch verder wilt gaan, gebruik dan
-fom reset te forceren.
U kunt dan de instructies volgen en uitvoeren met -f om de update te forceren:
# Postgres >= 10
pg_resetwal -f DATADIR
# Postgres < 10
pg_resetxlog -f DATADIR
Dat zou het transactielogboek moeten resetten, maar het kan uw database in een onbepaalde staat achterlaten, zoals uitgelegd in de PostgreSQL-documentatie op pg_resetwal :
Als
pg_resetwalklaagt dat het geen geldige gegevens kan bepalen voorpg_control, kunt u het forceren om toch door te gaan door de-f. op te geven (kracht) optie. In dit geval zullen plausibele waarden worden vervangen door de ontbrekende gegevens. De meeste velden zullen naar verwachting overeenkomen, maar er kan handmatige assistentie nodig zijn voor de volgende OID, volgende transactie-ID en tijdperk, volgende multitransactie-ID en offset, en WAL-startlocatievelden. Deze velden kunnen worden ingesteld met behulp van de hieronder besproken opties. Als u niet in staat bent om voor al deze velden de juiste waarden te bepalen,-fkan nog steeds worden gebruikt, maar de herstelde database moet met nog meer argwaan worden behandeld dan normaal:onmiddellijk dumpen en opnieuw laden is absoluut noodzakelijk. Voer geen bewerkingen voor het wijzigen van gegevens in de database uit voordat u deze dumpt, aangezien een dergelijke actie de corruptie waarschijnlijk zal verergeren.