Can a COMMIT statement (in SQL) ever fail? How?

Question

When working with database transactions, what are the possible conditions (if any) that would cause the final COMMIT statement in a transaction to fail, presuming that all statements within the transaction already executed without issue?

---

For example... let's say you have some two-phase or three-phase commit protocol where you do a bunch of statements, then wait for some master process to tell you when it is ok to finally commit the transaction:

-- <initial handshaking stuff> START TRANSACTION; -- <Execute a bunch of SQL statements> -- <Inform master of readiness to commit> -- <Time passes... background transactions happening while we wait> -- <Receive approval to commit from master (finally!)> COMMIT; 

If your code gets to that final COMMIT statement and sends it to your DBMS, can you ever get an error (uniqueness issue, database full, etc) at that statement? What errors? Why? How do they appear? Does it vary depending on what DBMS you run?

Answer 1

COMMIT may fail. You might have had sufficent resources to log all the changes you wished to make, but lack resources to actually implement the changes.

And that's not considering other reasons it might fail:

1. The change itself might not fit the constraints of the database.

2. Power loss stops things from completing.

3. The level of requested selection concurrency might disallow an update (cursors updating a modified table, for example).

4. The commit might time out or be on a connection which times out due to starvation issues.

5. The network connection between the client and the database may be lost.

And all the other "simple" reasons that aren't on the top of my head.

Answer 2

It is possible for some database engines to defer UNIQUE index constraint checking until COMMIT. Obviously if the constraint does not hold true at the time of commit then it will fail.