Re: deferred writing of two-phase state files adds fragility

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