Development News - October 2025

Query hangs when using forced PLAN that works automatically in Firebird 5

GitHub Issue: 8741 Affected versions: 5.0.3, 6.0 Initial

When executing a query, Firebird 5 automatically generates and successfully uses a specific execution plan in ~1 second. However, when the exact same plan is manually specified using the PLAN clause, the query hangs indefinitely.

Expected Behavior

The manually forced plan should execute with the same performance as the automatically chosen plan.

Actual Behavior

Query hangs/freezes when using the forced plan, requiring connection termination.

Replicator could produce log segments with duplicated segment numbers

GitHub Issue: 8755 Affected versions: 4.0.6, 5.0.3, 6.0 Initial Fixed for: 4.0.7, 5.0.4, 6.0 Alpha 1

File truncation errors may happen during replication in Windows CS

Pull Request: 8766 Affected versions: 4.0.6, 5.0.3, 6.0 Initial Fixed for: 4.0.7, 5.0.4, 6.0 Alpha 1

If journal_archive_command is specified in replication.conf and Windows CS is used on the master side, errors "Journal file truncate failed" may be raised under concurrent load.

Allow isc_tpb_read_consistency to imply read committed

Pull Request: 8746 Apply to: 5.0.4, 6.0 Alpha 1

We allow to specify isc_tpb_read_consistency alone and at least one driver currently specifies ReadCommitted ReadConsistency mode this way. However, in fact the transaction isolation becomes Snapshot with TRA_read_consistency flag being set too. This causes asserts in the code and I'm not really sure the chase/restart logic works properly in all cases.

Given that such a usage seems quite logical and handy, I suggest to not raise an error but rather imply ReadCommitted instead of Snapshot in this case.

Also, the transaction isolation detection in the trace was changed to be more resistant to weird flag combinations like the one described above and not raise unexpected asserts. It's now also in sync with the value of MON$ISOLATION_MODE.

Get the modification time of a config file with a higher precision

Pull Request: 8553 Apply to: 3.0.14, 4.0.7, 5.0.4, 6.0 Alpha 1

Remove/increase the record size limit

Pull Request: 7332 Apply to: 6.0 Alpha 1

This addresses ticket #1130. After compression improvements the storage overhead this is no longer an issue. I think we should still preserve some safety limit, e.g. 1MB. This change suggests some other improvements too, like compression of the stored temporary records (sorts, record buffers), but they may be addressed separately.

Early diagnostics for the improperly re-initialized replica

Pull Request: 8767 Apply to: 5.0.4, 6.0 Alpha 1

Detect cases when the replica is re-initialized with invalid sequence number (zero or older than expected -- in both cases replication cannot be continued) and report the error immediately. Replication may be resumed successfully if the replica database is replaced with a proper copy.

BIN_AND_AGG, BIN_OR_AGG, and BIN_XOR_AGG (BIN_AND, BIN_OR and BIN_XOR as aggregate functions)

GitHub Issue: 8175 Apply to: 6.0 Alpha 1

Add local/global scope modifiers for the db-info performance counters

GitHub Issue: 8771 Apply to: 6.0 Alpha 1

There are two goals for this change:

1. Fix ISQL's SET STAT; to report local (current connection) page counters instead of global (per database) counters, as it makes performance analysis hardly possible under concurrent load in SuperServer. There will be a separate PR for that.
2. Allow collection of database-wise performance counters using only Attachment::getInfo(), without any MON$ table access.

New scope tags are allowed to be intermixed inside a single info buffer, every scope tag affects only counters requested after it. Thus it's possible to collect e.g. per-database page counters and per-attachment record counters using a single API call, if this would be ever required. Scope tags are returned "as is" inside the output buffer (for consistency).

If scope tags are missing, the legacy behaviour (per-database page and memory counters, per-attachment record counters) is preserved for backward compatibility.

Downgrade compatibility supporting restore of v6 backups

GitHub Issue: 8750

It should be possible to downgrade v6 databases with gbak/restore into older versions (mainly v5).

That should be possible if there is no new feature usage. That normally happens, but due to schemas (that is not a opt-in feature), it requires additional code.

A v6 database with multiple schemas usage should be downgradable provided that there is no duplicate object names using different schemas.

Allow inline comments for fields, procedure parameters, and more

GitHub Issue: 8780

MySQL allows you to leave comments in place for table fields, as well as procedure and function parameters.

For example, for a table, it looks like this:

CREATE TABLE IF NOT EXISTS `mwr_essence`
(
    `CODE_ESSENCE`  int         NOT NULL AUTO_INCREMENT COMMENT 'ID',
    `CODE_GESSENCE` int         NOT NULL COMMENT 'Object type ID',
    `NAME`          varchar(50) NOT NULL COMMENT 'Security object name',
    PRIMARY KEY (`CODE_ESSENCE`),
    UNIQUE KEY `UNQ_ESSENCE` (`NAME`),
    KEY `FK_ESSENCE_GESSENCE` (`CODE_GESSENCE`)
) ENGINE = InnoDB
    COMMENT = 'Security objects'
  AUTO_INCREMENT = 1;

Example for a stored procedure and its parameters:

CREATE PROCEDURE SP_MW_GRANT_ROLE(
    IN A_MASTERROLE VARCHAR(50) COMMENT 'Master role name',
    IN A_DETAILROLE VARCHAR(50) COMMENT 'Detail role name',
    IN A_VALID INTEGER COMMENT 'If 1 then detail role is active, else is not active'
)
    SQL SECURITY INVOKER
    COMMENT 'Set role to another role'
BEGIN
/* ... */
END

Whereas in our case, descriptions of objects, table fields, and procedure parameters are created only separately using the COMMENT ON statement, which is usually located quite far from the column, parameter, or package procedure/function being described. It would be great to be able to leave in-place comments in Firebird as well. This would make metadata creation scripts clearer.