Bugs
Bugcheck when replicator state is changed concurrently
GitHub Issue: 8138 Affected versions: 5.0.0 Fixed for: 4.0.5, 5.0.1, 6.0 Alpha 1
Deadlock happens when run 'List Trace Sessions' service and there are many active trace sessions
GitHub Issue: 8151 Affected versions: 5.0.0 Fixed for: 3.0.12, 4.0.5, 5.0.1, 6.0 Alpha 1
The bug was found when few instances of QA tests was running concurrently.
The problem happens when textual representation for list of trace sessions takes more than 1KB (internal size of service output buffer) and service working thread runs faster than service start thread fire EVENT_SERVICE_START.
The hung or crash could happen when connection fires TRACE_EVENT_DETACH event and new trace session created concurrently
GitHub Issue: 8149 Affected versions: 5.0.0 Fixed for: 3.0.12, 4.0.5, 5.0.1, 6.0 Alpha 1
The bug was found when few instances of QA tests was run concurrently.
Can not specify concrete IPv6 address in ES/EDS connection string
GitHub Issue: 8156 Affected versions: 3.0.0, 4.0.0, 5.0.0 Fixed for: 3.0.12, 4.0.5, 5.0.1, 6.0 Alpha 1
Consider script:
set list on; set echo on; connect 'inet6://[::1]/employee'; select mon$remote_protocol as procotol_when_connect_from_isql from mon$attachments where mon$attachment_id = current_connection; set term ^; execute block returns(protocol_when_connect_by_es_eds varchar(20) ) as declare stt varchar(255) = 'select mon$remote_protocol from mon$attachments where mon$attachment_id = current_connection'; begin for execute statement (stt) on external 'inet6://[::1]/employee' as user 'SYSDBA' password 'masterkey' into protocol_when_connect_by_es_eds do suspend; end ^ set term ;^ commit;
On all current FB (3.x ... 6.x) it raises exception on ES/EDS:
Statement failed, SQLSTATE = 42000 External Data Source provider 'inet6://[' not found -At block line: 4, col: 13
Attempts find workaround (i.e. specify IPv6 using '[[' & ']]'; or to make some kind of 'escaping' via ''; or enclosing into double quotes) have no result.
ICU 63.1 suppresses conversion errors
GitHub Issue: 8108 Affected versions: 4.0.4, 5.0.0 Fixed for: 4.0.5, 5.0.1, 6.0 Alpha 1
FB4 returns an empty string when he can't translate Unicode symbol into ICU-codepage.
FB3 in this case returns an error.
Unicode symbol with code 0x115F (input string 'ᅟ')
Connection charset is NONE.
-- FB3 and FB4 are OK. select cast(_utf8 'ᅟ' as varchar(1) character set utf8) from rdb$database -- FB3 returns an error, FB4 OK (an error is expected) select cast(_utf8 'ᅟ' as varchar(1) character set tis620) from rdb$database -- FB3 and FB4 return an error (it is OK) select cast(_utf8 'ᅟ' as varchar(1) character set win1251) from rdb$database
The problem in new implementation of callback function UCNV_FROM_U_CALLBACK_STOP in ICU v63.1
In ICU v52 (FB3) this function does not contain any code
MAKE_DBKEY bug after backup/restore
GitHub Issue: 8168 Affected versions: 5.0.0 Fixed for: 5.0.1, 6.0 Alpha 1
Firebird relation ids are not stable. While some BLRs uses relation ids, BLR of stored code always refers to them by name.
However, system function MAKE_DBKEY transforms relation name to id and stores this id even in stored BLR.
After backup/restore, MAKE_DBKEY(name) is going to refer to different table.
New features/improvements
Cardinality estimation should use primary record versions only
GitHub Issue: 8161 apply to: 3.0.12
The issue was found on FB3 due to failed QA test for CORE-5602. While the test runs successfully on FB4-FB6, the issue is common for all versions.
Option for GEN_UUID to generate v7 UUID
GitHub Issue: 7980 apply to: 6.0 Alpha 1
UUID v7 more index-able than UUID v4(Current used in FirebirdSQL, CMIIW), please bring support for UUID v7 in FirebirdSql.
New feature/improvement requests
Provide ability to specify FW value directly in CREATE DATABASE statement
GitHub Issue: 8153
Please provide ability to specify FW value directly in CREATE DATABASE statement, e.g.:
CREATE DATABASE 'localhost:c:\temp\tmp4test.fdb' USER SYSDBA PASSWORD 'masterkey' ASYNC;
Ping function and events
GitHub Issue: 8122
fb_ping and Attachment::ping, in the case of tcp/ip connection, only checks the main connection.
When client registers events, I think it should also check the event connection, which may break while the main one is fine and application could just stop to receive events.