]> granicus.if.org Git - postgresql/commit
Improve handling of corrupted two-phase state files at recovery
authorMichael Paquier <michael@paquier.xyz>
Fri, 7 Sep 2018 18:00:16 +0000 (11:00 -0700)
committerMichael Paquier <michael@paquier.xyz>
Fri, 7 Sep 2018 18:00:16 +0000 (11:00 -0700)
commit8582b4d044b05d3fe4bcdf6e039fde8e753934ae
tree9ddacee248b29e398d44a2e378610e95bb2769a1
parent7b6b167fa3bd2f968ad885ca7b024be4122a85f1
Improve handling of corrupted two-phase state files at recovery

When a corrupted two-phase state file is found by WAL replay, be it for
crash recovery or archive recovery, then the file is simply skipped and
a WARNING is logged to the user, causing the transaction to be silently
lost.  Facing an on-disk WAL file which is corrupted is as likely to
happen as what is stored in WAL records, but WAL records are already
able to fail hard if there is a CRC mismatch.  On-disk two-phase state
files, on the contrary, are simply ignored if corrupted.  Note that when
restoring the initial two-phase data state at recovery, files newer than
the horizon XID are discarded hence no files present in pg_twophase/
should be torned and have been made durable by a previous checkpoint, so
recovery should never see any corrupted two-phase state file by design.

The situation got better since 978b2f6 which has added two-phase state
information directly in WAL instead of using on-disk files, so the risk
is limited to two-phase transactions which live across at least one
checkpoint for long periods.  Backups having legit two-phase state files
on-disk could also lose silently transactions when restored if things
get corrupted.

This behavior exists since two-phase commit has been introduced, no
back-patch is done for now per the lack of complaints about this
problem.

Author: Michael Paquier
Discussion: https://postgr.es/m/20180709050309.GM1467@paquier.xyz
src/backend/access/transam/twophase.c