Issue Details (XML | Word | Printable)

Key: CORE-973
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Ann Harrison
Reporter: Dmitry Yemanov
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

BUGCHECK(183) when attempting to backout a record version after a crash

Created: 23/Oct/06 10:35 AM   Updated: 26/Apr/07 12:33 PM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 1.5.4, 2.1 Alpha 1

Time Tracking:
Not Specified

 Description  « Hide
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

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

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Pavel Cisar added a comment - 26/Apr/07 11:41 AM
Reopened to update ticket information.