"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


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.

  1. Create USER ISQL:

    isql employee -user SYSDBA
    create user DBOwner password '1234' Grant Admin role;
  2. Create Database:

    CREATE DATABASE 'localhost/3050:primary.fdb'
    PAGE_SIZE 16384
  3. Copy Database to secondary.fdb

  4. Setup an async replication between primary.fdb and secondary.fdb

  5. Activate replication on primary side:

  6. Activate replication on secondary side:

    gfix -user DBOwner -pass 1234 -replica read_only  localhost/3051:secondary.fdb
  7. Create an other Table on primary side (Connected as DBOwner):

  8. 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
  9. Revoke delete from DBOwner on Table TEST2 on primary side:

    REVOKE delete on TEST2 from DBOWNER;
  10. 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


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.

Multi-character trim function

Pull request 8015 Apply to: 6.0 Alpha 1

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:

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.

Like this post? Share on: TwitterFacebookEmail

Related Articles



Reading Time

~6 min read