Issue Details (XML | Word | Printable)

Key: CORE-4390
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: prenosil
Votes: 0
Watchers: 4

If you were logged in you would be able to see more operations.
Firebird Core

Creation/altering of trigger with invalid BLR leaves its definition in the metadata cache

Created: 13/Apr/14 08:44 PM   Updated: 12/Jun/14 07:16 AM
Component/s: Engine
Affects Version/s: 2.1.5, 2.5.2, 2.1.5 Update 1, 2.5.2 Update 1, 3.0 Alpha 1, 3.0 Alpha 2
Fix Version/s: None

Issue Links:

 Description  « Hide
In my database there is one table I am UPDATing (works fine),
and another table that has trigger referencing first table.

By mistake I run ALTER TRIGGER which referenced non existing exception,
which raised (as excpected) error:

  Statement failed, SQLCODE = -104
  invalid request BLR at offset 34
  -exception ... not defined

However, since this moment I am not able to update the first table,
attempt to prepare the UPDATE will raise error

  Statement failed, SQLCODE = -901
  BLOB not found

Note 1 - there are no blobs in either of tables
Note 2 - the problem disappears after closing all connections (i.e. no permanent damage to the database)
Note 3 - tried with latest snapshots (FB2.5, FB3)
Note 4 - I was not able to create simple test script, however I will send database for testing (fresh/empty one)

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 15/Apr/14 08:45 AM
I have a feeling that the problematic blob is either RDB$TRIGGER_BLR or even more likely RDB$DEBUG_INFO. That said, surely a BLR parsing exception should not affect existing attachments, so it smells like a bug. I need a test database to validate the issue deeper, please send it to me directly or make it available for download. I will report back once I have it confirmed and debugged.

Dmitry Yemanov added a comment - 17/Apr/14 04:16 PM
Now I can confirm the problem. The origin of the issue is that somehow the new trigger definition (the invalid one, referencing non-existent exception) gets loaded into the metadata cache. When it's implicitly referenced by UPDATE, it gets compiled but fails when trying to read its debug info (blob was lost after rollback / backout so its blob id is no longer valid). The blob error is easy to fix but the issue persists, now the same error "exception ... not defined" is raised for UPDATE -- because the trigger is still invalid. The only solution is to disconnect (just current session for CS/SC or everybody for SS) and reconnect back.

I will post an update once the underlying caching issue is found and fixed.

Dmitry Yemanov added a comment - 12/Jun/14 07:15 AM
As both tickets (CORE-3305 and CORE-4390) reference the same issue consisting of two independent bugs, I'm renaming CORE-3305 to describe the "invalid BLOB ID" bug while CORE-4390 will describe the metadata cache bug.