At 07:09 PM 10/27/2004, Chad Z. Hower aka Kudzu wrote:

> internal gds software consistency check (Too many savepoints (287))
>
>Is this from a transaction that's too big? Even if so shouldn't FB just err
>and not crash? Also FB guardian does not restart it..

This is a bug that is fixed in 1.5.1 (I think). Despite the message
the problem is not too many savepoints, but too many save point lists.

Firebird keeps a savepoint list for every active verb, every procedure
or trigger, and a savepoint list for transaction operations. Those
lists allow it to undo the work of a verb (e.g. DELETE FROM <table>
will either delete all of the table or none of it), procedure, or
trigger. The transaction-level list undoes the work of a transaction
that rolls back deliberately. If the transaction level list gets too
long, it's discarded and a rollback, if it happens, is handled through
cooperative garbage collection.

There was a bug somewhere around the code that released savepoint lists
that Nickolay found some months ago. I believe that fix was backported
to 1.5. The effect of the bug was that Firebird found yet another
save point list after it thought it had got rid of all the ones it knew
about. You can avoid the possibility of this error by using the
no_auto_undo transaction option.

Regards,


Ann