Robert Haas <robertmhaas@gmail.com> writes:
> Let's suppose that you execute PREPARE TRANSACTION and, before the
> next CHECKPOINT, the WAL record for the PREPARE TRANSACTION gets
> corrupted on disk. This might seem like an unlikely scenario, and it
> is, but we saw a case at EDB not too long ago.
> To a first approximation, the world ends.
Ugh.
> You can't execute COMMIT
> TRANSACTION or ROLLBACK TRANSACTION, so there's now way to resolve the
> prepared transaction.
Could we fix it so ROLLBACK TRANSACTION removes the GID from the
list of prepared xacts that need to be written out? Then we'd
no longer have a pending requirement to read the broken WAL record.
> ... I'm not quite sure whether that's
> equivalent to a forced abort of the twophase transaction or whether it
> might leave you with some latent corruption, but I suspect the
> problems you'll have will be pretty tame compared to what happens in
> the scenario described above.
It should be fully equivalent to a database crash immediately before
committing an ordinary transaction. (I know various people keep
proposing that we load UNDO requirements onto transaction abort,
but I continue to think that's an awful idea, for precisely this
reason: you can't guarantee being able to execute the UNDO steps.
In any case, we don't have such requirements yet.)
regards, tom lane
