You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before DSQL was integrated into the engine in v2.5 it was y-valve who throws isc_bad_trans_handle.
It happens when DSQL tried to prepare statement and queries database.
In v2.5 DSQL called engine directly and few checks for valid transaction was introduced at metd.epp.
But, if object already exists at DSQL cache, this checks is bypassed and we trying to execute request
without a transaction.
In HEAD some checks performed before search in DSQL cache (at least in METD_get_relation) so,
my test case passed v3 successfully. But i see no harm to frontport fix from v2.5 into HEAD too.
Submitted by: @hvlad
I developing a tests using two transactions in the same attachments and found this bug.
Below is log of my test :
DDL: CREATE GLOBAL TEMPORARY TABLE T2 (ID INT) ON COMMIT PRESERVE ROWS
DDL: CREATE UNIQUE INDEX T2_UQ ON T2 (ID)
DDL: COMMIT
tx1: SET TRANSACTION READ COMMITTED NO VERSION NO WAIT
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, column 35
VERSION
tx1: INSERT INTO T2 VALUES (1)
invalid transaction handle (expecting explicit transaction start)
tx2: SET TRANSACTION SNAPSHOT NO WAIT
tx2: INSERT INTO T2 VALUES (1)
tx2: INSERT INTO T2 VALUES (2)
tx1: SELECT COUNT(*) FROM T2
internal Firebird consistency check (invalid block type encountered (147), file: exe.cpp line: 1015)
It was expected to got "invalid transaction handle" error there, not a bugcheck.
Note, i wrongly used "NO VERSION" instead of "NO RECORD_VERSION" therefore start of tx1 failed.
Commits: 6b7e763 293d5dc
The text was updated successfully, but these errors were encountered: