Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> On Tue, May 11, 2004 at 09:25:37PM +0100, Simon Riggs wrote:
>> Another way of putting it - if it was worth writing before a crash, it
>> is worth recovering after a crash. Surely?
> Right.
Wrong. Only actions that were *committed* before the crash, or in
general the selected recovery stopping time, need be recovered. The
actions-so-far of transactions that were in progress at that time don't
have to be redone. It doesn't really matter if we do do them; we have a
consistent database state either way. I'm just pointing this out for
the sake of clear thinking.
> What I was saying is that we don't need pg_subtrans info,
> because that's only needed while the subtransaction is marked as
> "subcommitted" but it's parent hasn't committed or aborted yet. The
> subcommitted status is changed to committed/aborted when the main
> transaction commits or aborts; at recovery time, we already know if that
> happenned or not so we can mark it right away.
Agreed, if pg_subtrans is never consulted except for children of
in-progress (or recently-completed) main transactions, then it need not
be recovered. However, I'm not sure this is really true. Couldn't
there be an entry in pg_clog showing a SUBTRANS COMMIT state immediately
after a recovery? If the main transaction never gets to commit or
abort, there would be nothing in XLOG to cue the recovery process to go
and clear that clog entry. So without some further mechanism I'd expect
the first backend that visits the tuple in question to go and consult
pg_subtrans. There would need to be a way of knowing "XIDs older than
this are by definition not to be sought in pg_subtrans". With a cutoff,
you could assume that SUBTRANS COMMIT entries older than the cutoff can
be changed to ABORT state.
What's not clear to me is how we can advance that cutoff; it might have
to go along with the clog truncation logic.
regards, tom lane
