| Subject | Re: [firebird-support] Re: error during savepoint backout (290) |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-12-14T08:37:50Z |
At 05:47 PM 14/12/2007, you wrote:
Here it was:
From memory, this error seems to be associated with situations where large numbers of inserts are done, with updates being done to the inserted records within the same transaction...the undo log goes wild or runs out of memory so that, when a rollback is requested, there are disjunct backversions in existence that are in conflict with the undo log....or something along these lines. I also have another (vague) memory of a workaround for this problem being to run the offending operations inside a transaction with no_update_log set. Just don't treat that as better than a hint - since your description gives no clue about what kind of operations are triggering the error - if you want to try it blind, try it on a database that you don't love.
If Ann spots this message, I hope she might have more light to shed on it, especially if you can provide some clues as to what the application is doing when this shows up.
./heLen
>Sorry, me again... :-)Is there anyone out here with superhuman memory who can remember a posting a week ago? ;-)
>Isn't there anybody who can tell me something about this problem? :-(
Here it was:
>One of our customers sometimes gets this error using version 2.0.1 SSIt was a known problem in InterBase 7.-something that was reported in 2004, although in that case it did corrupt the database in such a way that a backup and restore fixed it temporarily. ib-aid treats it as a problem with no known direct cause.
>on windows platform.
>
>Full error message in log file:
>
> deadlock
> internal gds software consistency check (error during savepoint
>backout (290), file: exe.cpp line: 3711)
>
>A validation of the database does not bring up any errors. And there
>is no need of a backup/restore. Just restarting the service seems to
>"solve" the problem.
>
>Any idea what might cause this problem and how it can be avoided?
>Is it a known bug?
>
>--Heiko
From memory, this error seems to be associated with situations where large numbers of inserts are done, with updates being done to the inserted records within the same transaction...the undo log goes wild or runs out of memory so that, when a rollback is requested, there are disjunct backversions in existence that are in conflict with the undo log....or something along these lines. I also have another (vague) memory of a workaround for this problem being to run the offending operations inside a transaction with no_update_log set. Just don't treat that as better than a hint - since your description gives no clue about what kind of operations are triggering the error - if you want to try it blind, try it on a database that you don't love.
If Ann spots this message, I hope she might have more light to shed on it, especially if you can provide some clues as to what the application is doing when this shows up.
./heLen