Submitted by: @AlexPeshkoff
Nothing limits use of rather complex expression in the index. One can use selectable stored procedure to calculate that expression, and in that stored procedure one can select rows from the table on which expression index is created. During garbage collection of such index key value is calculated which causes expression evaluation, execution of SP and tabke scan - which in turn causes GC. I.e. we have unlimited recursion with obvious stack overflow and segfault.
Commits: 5bbf69b dc9e026 fbb7068 2caa4f7 1eba28b 35282da a4c886a 606e9e3
====== Test Details ======
Case when SP tries to change record via ES+EDS mechanism remains uncovered.
ISQL will hang and, though it can be interrupted by Ctrl-C, firebird process keeps DB file opened infinitely.
Discussed with Vlad, letters 17.04.2021 09:52 and 21.04.2021 10:40.
Submitted by: @AlexPeshkoff
Nothing limits use of rather complex expression in the index. One can use selectable stored procedure to calculate that expression, and in that stored procedure one can select rows from the table on which expression index is created. During garbage collection of such index key value is calculated which causes expression evaluation, execution of SP and tabke scan - which in turn causes GC. I.e. we have unlimited recursion with obvious stack overflow and segfault.
Commits: 5bbf69b dc9e026 fbb7068 2caa4f7 1eba28b 35282da a4c886a 606e9e3
====== Test Details ======
Case when SP tries to change record via ES+EDS mechanism remains uncovered.
ISQL will hang and, though it can be interrupted by Ctrl-C, firebird process keeps DB file opened infinitely.
Discussed with Vlad, letters 17.04.2021 09:52 and 21.04.2021 10:40.