Re: [Firebird-devel] QA Tests
On 20/07/2018 01:30, Dmitry Yemanov wrote:
> 20.07.2018 04:59, Adriano dos Santos Fernandes wrote:
>>
>> When I run the QA tests, some tests results in FAIL and others result in
>> ERROR.
>>
>> What is the differences between these results?
>
> FAIL means the test executed OK, but its output doesn't match the
> expected one. ERROR means something bad happened so that the test
> couldn't execute properly - usually it means python runtime error,
> unhandled FB exceptions, failed pre-requisite actions, etc.
>
>> I run it with this command:
>>
>> /fb/fbtest/fbtest.py \
>> --bin-dir $FIREBIRD/bin \
>> --host localhost \
>> --client $FIREBIRD/lib/libfbclient.so \
>> --db-dir /tmp/fbtest/db \
>> --xunit \
>> --verbose
>
> I use the helper binaries: fbt_run / fbt_archive / fbt_analyze.
>
>> Should different options be used for different Firebird versions?
>
> Nope, AFAIK.
>
>> How to produce a report like ones present in
>> http://web.firebirdsql.org/download/prerelease/results/3.0.4.33010/ ?
>
> fbt_analyze
>
Thanks. Didn't known about these utilities.
But I have problem with many tests, that returns empty stdout.
For example:
==
FAIL: bugs.core_1171
--
Expected standard output from ISQL does not match actual output.
--
Ran 1 tests in 0.494s
FAILED (fails=1)
ISQL_stdout_actual is empty.
To make it work, I need to change test from:
'test_script': "select cast ('-2.488355210669293e+39' as double
precision) from rdb$database;",
to:
'test_script':
"""
select cast ('-2.488355210669293e+39' as double precision) from
rdb$database;
""",
What is happening?
This is with FB 3 - release and debug in Linux.
Adriano
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] CORE-5877 Garbage in the compound index after several updates
Not exactly so. When index key is not changed by UPDATE statement, engine doesn't add it into the index. Ok, so it has not changed. tx1: insert record (r1) with index key (k1) >> table contains one record version: r1-tx1 >> index contains one entry: (k2, r1) tx1: commit tx2: update r1 set key = k2 >> table contains two records versions: r1-tx2, r1-tx1 >> index contains two entries: (k1, r1), (k2, r1) tx2: commit garbage collector: >> remove from disk r1-tx1, >> build lists: staying (r1-tx2), going (r1-tx1) >> going to cleanup indices >> context switch... >> table: r1-2 >> index: (k1, r1), (k2, r1) tx3: update r1 set key = k1 >> table: r1-tx3, r1-tx2 >> index: (k1, r1), (k2, r1) note, tx3 doesn't add index entry (k1, r1) as it is already present tx3: commit garbage collector: >> ...continue to cleanup indices >> lists: staying (r1-tx2), going (r1-tx1) >> keys: staying (k2), going (k1) >> remove index key (k1, r1) On disk >> table: r1-tx3, r1-tx2 >> index: (k2, r1) r1-tx3 contains key = k1, but index have no such entry Very informative, thank you very much. Above describe the problem, but how it was fixed after FB2 that we have now this issue? regards, Karol Bieniaszewski -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] CORE-5877 Garbage in the compound index after several updates
20.07.2018 14:45, liviuslivius wrote: Hi, i ask here to not spam into the tracker. I know that indexes in Firebird are not transactional objects. My understanding was that when we update record then old record vesion go to new place and new record version replace place where old record version was. More-or-less correct This prevent for updating index entry when nothing in the indexed fields was changed. > But now i read that: >> So, many years ago (when FB 2.0 was developed, iirc), algorithm above was changed a bit - since then Firebird >> engine adds index key despite of its presence with the same record number. >> This could lead to the non-removable keys but it is much less evil than missed entries. do i understand correctly that now it store new entry always? Not exactly so. When index key is not changed by UPDATE statement, engine doesn't add it into the index. And it store with link to the same record not to old record version? > >> This doesn't work in concurrent environment, unfortunately, and could produce index with missed entries (which is >> very serious problem). I don't want to go too deep into details here. > Maybe you can bring light here if not on the tracker? tx1: insert record (r1) with index key (k1) table contains one record version: r1-tx1 index contains one entry: (k2, r1) tx1: commit tx2: update r1 set key = k2 table contains two records versions: r1-tx2, r1-tx1 index contains two entries: (k1, r1), (k2, r1) tx2: commit garbage collector: remove from disk r1-tx1, build lists: staying (r1-tx2), going (r1-tx1) going to cleanup indices context switch... table: r1-2 index: (k1, r1), (k2, r1) tx3: update r1 set key = k1 table: r1-tx3, r1-tx2 index: (k1, r1), (k2, r1) note, tx3 doesn't add index entry (k1, r1) as it is already present tx3: commit garbage collector: ...continue to cleanup indices lists: staying (r1-tx2), going (r1-tx1) keys: staying (k2), going (k1) remove index key (k1, r1) On disk table: r1-tx3, r1-tx2 index: (k2, r1) r1-tx3 contains key = k1, but index have no such entry >> So far i have no good solution for this problem. > if described in details, more heads can got some concept how to solve this. regards, This is old and well known in this list (at least) problem Regards, Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] CORE-5877 Garbage in the compound index after several updates
Hi, i ask here to not spam into the tracker. I know that indexes in Firebird are not transactional objects. My understanding was that when we update record then old record vesion go to new place and new record version replace place where old record version was. This prevent for updating index entry when nothing in the indexed fields was changed. But now i read that: >> So, many years ago (when FB 2.0 was developed, iirc), algorithm above was >> changed a bit - since then Firebird >> engine adds index key despite of its presence with the same record number. >> This could lead to the non-removable keys but it is much less evil than >> missed entries. do i understand correctly that now it store new entry always? And it store with link to the same record not to old record version? >> This doesn't work in concurrent environment, unfortunately, and could >> produce index with missed entries (which is >> very serious problem). I don't want to go too deep into details here. Maybe you can bring light here if not on the tracker? >> So far i have no good solution for this problem. if described in details, more heads can got some concept how to solve this. regards, Karol Bieniaszewski-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdotFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
