Server crashes while restoring a database having an expression index referencing a non-existent UDF [CORE2914] #3298
Comments
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovstatus: Open [ 1 ] => In Progress [ 3 ] |
|
Commented by: Andrei Kireev (andreik) I would vote for second option. |
Modified by: @dyemanovstatus: In Progress [ 3 ] => Open [ 1 ] |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.5 RC3 [ 10381 ] Fix Version: 2.1.4 [ 10361 ] Fix Version: 3.0 Alpha 1 [ 10331 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] QA Status: Not enough information Test Details: Wait for reply from dimitr on letter about problem with restoring .fbk under fbt-run, date: 14-may-2015 22:41. |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] Test Details: Wait for reply from dimitr on letter about problem with restoring .fbk under fbt-run, date: 14-may-2015 22:41. => Log of fbt_run:E
|
firebird-automations
added
affect-version: 2.5 RC2
affect-version: 2.5 RC1
affect-version: 3.0 Initial
affect-version: 2.1.3
affect-version: 2.5 Beta 2
affect-version: 2.5 Beta 1
affect-version: 2.1.2
affect-version: 2.0.5
affect-version: 2.1.1
affect-version: 2.5 Alpha 1
affect-version: 2.0.4
affect-version: 2.1.0
affect-version: 2.0.3
affect-version: 2.0.2
affect-version: 2.0.1
affect-version: 2.0.0
fix-version: 2.5 RC3
fix-version: 2.1.4
fix-version: 3.0 Alpha 1
resolution: fixed
priority: major
labels
Submitted by: @dyemanov
In the past, the engine has been made "smart enough" to not interrupt the restore process if some UDF library is missing. Instead, GBAK prints a warning and the process continues. But if some expression index references the missing UDF, the engine crashes while trying to call that UDF while creating the index.
We could throw an error and terminate the restore process in this case. Another alternative would be to restore such an index as inactive, with an appropriate message printed into stderr.
Commits: eadb960 e26e17c dc92d8e
====== Test Details ======
Log of fbt_run:
E
ERROR: bugs.core_2914
Database restore
Unexpected stderr stream received from GBAK.
-- looks like the database can`t be restored.
But this message happens ONLY inside fbt_run, because gbak itself DOES finish of restoring process!
Command:
gbak.exe -rep core2914-ods12.fbk host/port:path\tmp2914.fdb -v 1>log 2>err
-- produces file `err'` with ZERO size (empty) and `log`with mesages:
. . .
gbak: restoring privilege for user SYSDBA
gbak:creating indexes
gbak: activating and creating deferred index TEST_X_REVERSE
gbak:cannot commit index TEST_X_REVERSE
gbak: ERROR:function ID_REVERSE is not defined
gbak: ERROR: module name or entrypoint could not be found
gbak: ERROR: function ID_REVERSE is not defined
gbak: ERROR: module name or entrypoint could not be found
gbak:committing metadata
gbak:fixing views dbkey length
gbak:updating ownership of packages, procedures and tables
gbak:adding missing privileges
gbak:fixing system generators
gbak:finishing, closing, and going home <<<<<<<<<<<<<<<<<<<<<<<<<<<<< !! OK !! <<<<<<<<<<<<<<<<<
gbak:adjusting the ONLINE and FORCED WRITES flags
Wait for reply from dimitr on letter about problem with restoring .fbk under fbt-run, date: 14-may-2015 22:41.
The text was updated successfully, but these errors were encountered: