Firebird Documentation Index → Firebird 2.5 Release Notes → Changes in the Firebird Engine → Improvements |
Improvements implemented include:
The Classic server now detects immediately when a Classic process has been broken by a client disconnection. Its response is to terminate any pending activity, roll back the active transaction and close the network connection.
Tracker reference CORE-818.
Important optimizations include:
An optimization improves data retrieval performance for tables from which no fields are accessed. This applies, for example to the SELECT COUNT(*) style of query.
Tracker reference CORE-1598.
An optimization avoids memory consumption of <page size> bytes for each temporary BLOB created during assignment.
Tracker reference CORE-1658.
The aim of this improvement was to reduce the amount of precedence writing that the engine undertakes when performing its “careful write” procedure for updates. The existing procedure had a noticeable effect on the performance of mass updates, especially for “updates-in-place”, where the same records are updated more than once in the same transaction. In the worst case, a page could be written to disk for every single new record version created during an update.
See the Tracker reference (CORE-2672)for a simplified technical description of what was involved internally.
The solution addresses the potentially time-consuming process involved in protecting the write operations from causing circular references between the pages on which new record versions and back versions are placed to maintain correct precedence.
Tracker reference CORE-1687
Previous 64-bit Firebird server versions could not benefit from 64-bit address space and be configured for more than 2 GB (16K * 128 K)of database cache. The problem has been rectified in this version. On 64-bit Firebird, if the resources are available, it is now possible to configure cache large enough to accommodate a database of 5-10 GB completely in RAM .
Although Firebird's caching can get a lot of help from the filesystem cache, it is a feature that could be important for high-throughput systems whose load is mainly reads. The theoretical upper limit for caches on x64 Firebird servers is now 2^31 -1 (2,147,483,647) pages.
Tracker reference CORE-1643
The configuration parameter DatabaseAccess now has more “meaning” attached to it. In the absence of any other indication, the first location defined in the “Restrict” list for DatabaseAccess is taken by the engine as the default location for creating a new database and for locating a database where the connection parameters do not specify either an alias or the full path specification.
The seek logic is similar to that use for finding external tables from the Restrict list supplied to the ExternalFileAccess parameter, viz.,
All directories in the Restrict list are searched first.
If the database specified is not found:
If CREATE DATABASE is involved, then the first location in the Restrict list is used.
Otherwise, the attach fails in the expected fashion.
This feature does not suppress the use of the current working directory as the implicit location of the specified database file for direct local connections. The Y-valve handles the path resolution in these cases, just as it ever did.
For a stand-alone server working via the remote subsystem, trying to connect using the database file name with no path, although unlikely, is not recommended, since there is not really any way to be certain where the database would “land”. On Windows, for example, under these conditions the current working directory would be %system%.
The root determination mechanism for the Windows embedded engine has been changed to avoid common problems that occur when an installation of the application structure encounters “DLL Hell”. Previously, the implicit root directory was the directory containing the user application's main executable file. Now it is the directory where the renamed fbembed.dll library is located.
Tracker reference CORE-1814.
Previous Firebird versions used 32-bit I/O when working with external tables, limiting the size of the external file to < 2 GB. The mechanism has been enhanced to use 64-bit I/O on filesystems that support it, effectively eliminating the 2 GB limit.
Tracker reference CORE-2492.
Tracker reference CORE-2619
Memory and other statistics did not work properly 64-bit values in older Firebird versions. The issue had two parts:
To make the engine use 64-bit integers for statistics, the internals of AtomicCounter were changed.
The isql and qli tools had to be taught to work with 64-bit values.
To enable the 32-bit tools to work correctly with a 64-bit server, it was necessary to introduce some new internal API functions (struct perf64 and perf64_xxx) and change isql and qli to use them. This means that the isql and qli programs in V.2.5 are not compatible with older Firebird clients.
Tracker reference CORE-1937.
When a string UDF is written to return a pointer not allocated by the same runtime as the Firebird server is accessing, the presence of the FREE_IT keyword in its declaration corrupts memory and crashes the server. As a safeguard against such dysfunctional UDFs, the engine now
detects such UDFs and throws an exception
depends on the presence of the updated ib_util library in the path for all server models, including embedded
Better diagnostics and error reporting when TPB contents are malformed. The new TPB validation logic now rejects:
explicitly conflicting options within the same category, e.g., {WAIT} and {NOWAIT} specified together, or {READ COMMITTED} and {SNAPSHOT}, or {READ ONLY} and {WRITE}
options making no sense, e.g. [NO] RECORD VERSION specified for a SNAPSHOT isolation mode
incorrect order of table reservation options, e.g. {PROTECTED READ <TABLE>} instead of {READ <TABLE> PROTECTED}
Tracker reference CORE-1600.
Both table and column names are now reported when access privilege exceptions occur for a column.
Tracker reference CORE-1234.
Tracker reference CORE-2587
The diagnostic message when the engine cannot create shared memory that has already been mapped by another engine process in another Windows session is now a bit more user-friendly. It used to say:
The requested operation cannot be performed on a file with a user-mapped section open.
Now, it says:
Database is probably already opened by another engine instance in another Windows session.
An improvement allows the current value of RDB$DEFAULT_COLLATE_NAME in the system table RDB$CHARACTER_SETS to survive the backup/restore cycle. The mechanism for such customisation is the new ALTER CHARACTER SET command.
Tracker reference CORE-789.
Firebird Documentation Index → Firebird 2.5 Release Notes → Changes in the Firebird Engine → Improvements |