> According the the Firebird Book, if a transaction inserts a huge
> number of rows, and is rolled back, the row images created by those
> inserts may not be erased from the disk.

My understanding is that it depends on the rollback. If the client
explicitly calls rollback, then the server runs through an undo log to
reverse out the changes it has already done, then commits. This is a
'user pays' type situation, the transaction that causes the garbage is
given the broom and told to clean up its own mess.

If the client abandons the connection, then eventually the server will
recognise this and flag the transaction as rolled back, and the next
transaction who was just in the wrong place at the wrong time is
handed the broom and told to do the cleanup. This is something one
needs to be careful of when complaining about the performance of a
given query - it may not be the query that is the problem but rather
the transaction was lumped with the responsibility of cleaning up the
garbage as it went.

Actually, I missed the word huge. Huge may mean so many that the undo
log has taken up so much space that the engine decides that it is less
expensive to abandon the log and deal with rollbacks the same way as
an abandoned connection caused rollback.

> Will a sweep remove these images?

That depends on your understanding of remove.

A sweep will run through and flag any no-longer-used record versions
as available to be reused. It does not go through with a military
level writing 0s, then writing 1s then writing random data, 5 million
times so that the data is definately gone, and it does not return the
space occupied by the 'image' back to the operating system.

Adam