<p>I am studying how two-phase commit works across a distributed transaction. It is my understanding that in the last part of the phase the transaction coordinator asks each node whether it is ready to commit. If everyone agreed, then it tells them to go ahead and commit.</p>

<p>What prevents the following failure?</p>

<ol>
<li>All nodes respond that they are
ready to commit</li>
<li>The transaction
coordinator tells them to "go ahead
and commit" but one of the nodes
crashes before receiving this
message</li>
<li>All other nodes commit successfully, but now the distributed transaction is corrupt</li>
<li>It is my understanding that when the crashed node comes back, its transaction will have been rolled back (since it never got the commit message)</li>
</ol>

<p>I am assuming each node is running a normal database that doesn't know anything about distributed transactions. What did I miss?</p>

No.  Point 4 is incorrect.  Each node records in stable storage that it was able to commit or rollback the transaction, so that it will be able to do as commanded even across crashes.  When the crashed node comes back up, it must realize that it has a transaction in pre-commit state, reinstate any relevant locks or other controls, and then attempt to contact the coordinator site to collect the status of the transaction.
The problems only occur if the crashed node never comes back up (then everything else thinks the transaction was OK, or will be when the crashed node comes back).