Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUGCHECK(183) when attempting to backout a record version after a crash [CORE973] #1377

Closed
firebird-automations opened this issue Oct 23, 2006 · 9 comments

Comments

@firebird-automations
Copy link
Collaborator

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @pcisar

Reopened to update ticket information.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Closed [ 6 ] => Reopened [ 4 ]

resolution: Fixed [ 1 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Fix Version: 2.1 Alpha 1 [ 10150 ]

Fix Version: 2.1.0 [ 10041 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Reopened [ 4 ] => Closed [ 6 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 11278 ] => Firebird [ 15362 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test => Cannot be tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant