Bugs
"no current record for fetch operation" error with select stored procedures
GitHub Issue: 8036 as duplicate to 7937 Affected versions: 3.0.11, 4.0.4, 5.0.0 Fixed for: 6.0 Alpha 1
There's a bug working with selectable stored procedures. It appears only under certain conditions with specific SQL contructs.
Segfault when opening damaged database
GitHub Issue: 8039 Affected versions: 4.0.4, 5.0.0 Fixed for: 4.0.5, 5.0.1
Conditions: last TIP is missing in RDB$PAGES, user's FW was OFF
When required TIP is not found by DPM_scan_pages() it's force-loaded by inventory_page() function but if that happens before TPC initialization is complete an attempt to compile request in DPM_pages() leads to segfault when getting attachment's ID from that cache.
AV when both function and dependent table are dropped in the same transaction
GitHub Issue: 8020 Affected versions: 6.0 Initial Fixed for: 6.0 Alpha 1
Invalid result when string compared with indexed numeric(x,y) field where x > 18 and y != 0
GitHub Issue: 8033 Affected versions: 5.0.0, 6.0 Initial Fixed for: 5.0.1, 6.0 Alpha 1
SQL> create table mi8 (v numeric (30, 4)); SQL> insert into mi8 values(12.345); SQL> commit; SQL> create index i8 on mi8(v); SQL> select * from mi8 where v = 12.345; -- result is correct ============================================= 12.3450 SQL> select * from mi8 where v = '12.345'; -- result is wrong
Bugcheck 183 (wrong record length) could happen on replica database after UK violation on insert
GitHub Issue: 8040 Affected versions: 4.0.4, 5.0.0, 6.0 Initial Fixed for: 4.0.5, 5.0.1, 6.0 Alpha 1
The conditions:
replica database contains a table with Primary Key and at least one Unique Key
the record is being inserted and violates UK (not PK!)
the correct error is put into replication.log:
ERROR: attempt to store duplicate value (visible to active transactions) in unique index <UK name> Problematic key value is (...)
after replication paused and resumed the same segment is applied again
bugcheck happens: ERROR: internal Firebird consistency check (wrong record length (183), file: vio.cpp line: 1450)
DDL-Changes in replication does not set the correct grantor
GitHub Issue: 8058 Affected versions: 4.0.4, 5.0.0, 6.0 Initial Fixed for: 6.0 Alpha 1
Here is a way how to reproduce it in FB 4.0.4 and 5.0.
Create USER ISQL:
isql employee -user SYSDBA create user DBOwner password '1234' Grant Admin role;
Create Database:
CREATE DATABASE 'localhost/3050:primary.fdb' USER 'DBOWNER' PASSWORD '1234' PAGE_SIZE 16384 DEFAULT CHARACTER SET UTF8 COLLATION UTF8; RECREATE TABLE TEST1 ( ID INTEGER GENERATED BY DEFAULT AS IDENTITY, CONSTRAINT PK_TEST1 PRIMARY KEY (ID) );Copy Database to secondary.fdb
Setup an async replication between primary.fdb and secondary.fdb
Activate replication on primary side:
ALTER DATABASE INCLUDE ALL TO PUBLICATION ALTER DATABASE ENABLE PUBLICATION
Activate replication on secondary side:
gfix -user DBOwner -pass 1234 -replica read_only localhost/3051:secondary.fdb
Create an other Table on primary side (Connected as DBOwner):
RECREATE TABLE TEST2 ( ID INTEGER GENERATED BY DEFAULT AS IDENTITY, CONSTRAINT PK_TEST2 PRIMARY KEY (ID) )Have a look, who is the Grantor:
select * from RDB$USER_PRIVILEGES where RDB$USER_PRIVILEGES.rdb$relation_name = 'TEST2' In Primary: RDB$User = DBOWNER and RDB$GRANTOR = DBOWNER In Secondary: RDB$User = DBOWNER and RDB$GRANTOR = SYSDBA
Revoke delete from DBOwner on Table TEST2 on primary side:
REVOKE delete on TEST2 from DBOWNER;
Replication does not work anymore
replocation.log: DBOWNER is not grantor of DELETE on TEST2 to DBOWNER.
My expectation is that the Grantor on the secondary side is the same as on the primary side. Or that you can specify in the config file who executes the replication statments on the secondary side.
Firebird 5: (var)char variables/parameters assignments fail in Stored Procedures with subroutines
GitHub Issue: 8063 Affected versions: 5.0.0, 6.0 Initial Fixed for: 5.0.1, 6.0 Alpha 1
Changes
Crash with SIGBUS when there is no free space on the partition with memory-mapped files
Fixed for: 4.0.5, 5.0.1, 6.0 Alpha 1
The crash occurs because the memory-mapped files are extended using ftruncate and it doesn't allocate space on disk for the new file blocks. And later when we try to use the extended space without underlying disk blocks on 100%-filled partition we get SIGBUS error. Here are some explanations: https://mapdb.org/blog/mmap_file_and_jvm_crash/. It can be reproduced for example by mounting tmpfs filesystem with a limited size (10 Mb) in /tmp/firebird directory.
After a certain load, the engine will try to extend the memory-mapped file (usually lock or monitoring). This will not cause an error, although there is no disk space in /tmp/firebird for it. But later on an attempt to use the extended memory (memset, memcpy, trivial assignment) the server will crash with SIGBUS.
The problem can be solved by allocating disk blocks for extended space: https://uk.comp.os.linux.narkive.com/Ve44sO4i/shared-memory-problem-no-space-at-dev-shm-causes-sigbus
Here it is suggested to write zeros to the end of the file, but as testing has shown, fallocate also works.
Windows doesn't have this problem, SetFilePointer call returns error 112 (There is not enough space on the disk.).
New features/improvements
Wrong cardinality estimation because of empty data pages
GitHub Issue: 8030 Apply to: 3.0.12, 4.0.5, 5.0.1, 6.0 Alpha 1
When making a cardinality estimation, the optimizer does not take empty data pages into account. In the test case DB, this resulted in a sub-optimal plan. Noticed with Firebird 4, but Firebird 5 is also affected.
Improve conflict resolution on replica when table have both Primary and Unique keys
GitHub Issue: 8042 Apply to: 4.0.5, 5.0.1, 6.0 Alpha 1
The setup is the same as in 8040:
- replica database contains a table with Primary Key and at least one Unique Key
- the record is being inserted and violates UK (not PK!)
Currently, PK violation on insert is resolved by updating conflicting record, using the PK fields values.
But case with UK violation can't be resolved as engine tries to find record for update using PK and such record obviously can't be found, thus original error is returned. This stops replication until manual correction by DBA.
Improvement is to update record using not PK but the unique index that was violated on insert. In this case record exists and can be updated. Replication process will continue.
Let optimizer automatically update empty index statistics for relatively small system tables
Pull request 8057 Apply to: 6.0 Alpha 1
This is experimental change.
It should allow to get correct execution plan for system queries when index statistics is empty, for example at the restore.
New feature/improvement requests
databases.conf syntax enhancement
GitHub Issue: 8050
Occasionally, it becomes necessary to specify certain parameters for a database in the databases.conf file. However, there might be cases where creating an alias for these parameters is not desirable. Currently, the only available approach to achieve this in databases.conf is by using a workaround like:
c:\path\mydb.fdb = c:\path\mydb.fdb
{
DefaultDbCachePages = 10000
}
For such cases, it would be easier if we could do just something like this:
c:\path\mydb.fdb
{
DefaultDbCachePages = 10000
}
Option for GEN_UUID to generate v7 UUID
GitHub Issue: 7980
UUID v7 more index-able than UUID v4 (currently used in FirebirdSQL).
Create if not exists
GitHub Issue: 8062
Latest snapshot builds includes "drop if exists" support (at least for tables). Both "drop if exists" and "create if not exists" has been discussed in several other places including 4203
Since half of the job seems to be implemented, I would very much like to have the other half for v6.0.
Other open issues
BLOB type is not preserved by replication
Stream BLOBs become segmented in target database.
Update 'Blob sub_type 0' in FB 3/4/5 is so much slower than in FB 2.5
One Firebird user discovered that BLOB of subtype 0 updates are slower on Firebird v3, 4 and 5 in comparison to version 2.5. This slow down was confirmed by core develoepers, but the reason and its extent needs to be further investigated.