Submitted by: @dyemanov

Assigned to: Ann Harrison (awharrison)

The wrong length record errors occurred with 1.5.3 and 2.0
head servers. About sixty records were affected.

The primary version of every record affected was created
by a transaction that was rolled back. The TIPs showed
clusters of failed transactions and the owner said that
they had had a procedure that ran the system out of memory.
So, the transactions probably failed because of a server
crash and the automatic rollback did not happen.

Inspection showed that each of the records had at least
two versions. The primary record version had a record flag
value of 33 - meaning that the record marked as deleted and
that the back version was a delta. That delta version was
created by same dead transaction. Most of the records were
fragmented. The failure came when the delta record was
handled as if it were a full record.

The error occurred during the backout of the primary
record version - created by a dead transaction. It
appears that the backout code doesn't handle the case
of a delta as the back version of a deleted record
created by a dead transaction.

That situation is unusual - in fact, it didn't happen in
early versions of InterBase. When a record was deleted,
InterBase always created a new stub record that held the
deleted flag and the TID of the transaction that deleted
it.

Here's what I think is going on. The dead transaction
modified the record several times at several levels of
savepoint - as would happen if the updates were in
stored procedures. Sometime around Version 6, InterBase
learned that if a record is updated then deleted at the
same savepoint level, with a safe back version available,
the delete flag can be set in the updated record version,
rather than creating a stub record.

So why haven't we seen this all over? Probably because it
requires both an elaborate update/delete cycle, and a crash.
The normal failed transaction undo code handles this case
correctly.