You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Historically, transaction ID space was limited by 2^31 transactions (started since the database creation time). After that point, the database becomes unavailable until backup/restore is performed, which resets the transaction ID back to zero. Initial Firebird 3.0 version increased the transaction ID space to 2^32 transactions which doubles the database uptime without backup/restore.
This improvement request is about shifting that limit even further.
Firebird 3.0 RC1 introduces 48-bit internal transaction IDs that are publicly (via API and MON$ tables) represented as 64-bit numbers. This makes the new limit roughly equal to 2.8*10^14 transactions, later it could be extended up to the 2^63 limit. The implemented solution has no additional storage overhead until the transaction counters grow beyond the 2^32 boundary.
While being there, attachment IDs and statement IDs were changed to 64-bit numbers (both internally and externally).
Database with Tx counters about 2.8*10^14 can not be prepared at reasonable time.
Direct updating of .fdb file (its TIP page) can lead to server crash after attempting to connect - so this ticket can not be tested by using fbtest.
The text was updated successfully, but these errors were encountered:
Test Details: Database with Tx counters about 2.8*10^14 can not be prepared at reasonable time.
Direct updating of .fdb file (its TIP page) can lead to server crash after attempting to connect - so this ticket can not be tested by using fbtest.
Submitted by: @dyemanov
Relate to DNET896
Historically, transaction ID space was limited by 2^31 transactions (started since the database creation time). After that point, the database becomes unavailable until backup/restore is performed, which resets the transaction ID back to zero. Initial Firebird 3.0 version increased the transaction ID space to 2^32 transactions which doubles the database uptime without backup/restore.
This improvement request is about shifting that limit even further.
Firebird 3.0 RC1 introduces 48-bit internal transaction IDs that are publicly (via API and MON$ tables) represented as 64-bit numbers. This makes the new limit roughly equal to 2.8*10^14 transactions, later it could be extended up to the 2^63 limit. The implemented solution has no additional storage overhead until the transaction counters grow beyond the 2^32 boundary.
While being there, attachment IDs and statement IDs were changed to 64-bit numbers (both internally and externally).
Commits: 1ae6a9b 4e4d800 FirebirdSQL/fbt-repository@157dc9b FirebirdSQL/fbt-repository@4642bd0
====== Test Details ======
Database with Tx counters about 2.8*10^14 can not be prepared at reasonable time.
Direct updating of .fdb file (its TIP page) can lead to server crash after attempting to connect - so this ticket can not be tested by using fbtest.
The text was updated successfully, but these errors were encountered: