Heikki Linnakangas <hlinnaka@iki.fi> writes:
> In step 3.1, is it safe to skip gxacts not marked as valid? The gxact is
> marked as valid after the prepare record is written to WAL. If checkpoint
> runs after the WAL record is written but before the gxact is marked as
> valid, it doesn't get fsynced. Right?
It's safe because we have the CheckpointStartLock: no checkpoint
occurring in that interval can be trying to set its redo pointer
after the PREPARE record. This is essentially the same race condition
previously detected for COMMIT vs. writing clog, and we need the
interlock with either approach to fsyncing 2PC.
> This reminds me of something. What should we do about XID wraparounds and
> prepared transactions?
I don't think we need any special protection. The prepared xacts will
be blocking advancement of GlobalXmin, and the (new in 8.1) XID wrap
detection code will shut us down safely.
> A transaction shouldn't live that long in normal use, but I can imagine an
> orphaned transaction sitting there for years if it doesn't hold any locks
> etc that bother other applications.
No, because people will notice the effects on VACUUM if nothing else.
> I don't think we should implement heuristic commit/rollback, though.
> That creates a whole new class of problems.
Agreed. I did put in the time-of-prepare display in pg_prepared_xacts,
so anyone who really wants this can program the behavior they want from
outside the database.
regards, tom lane
