Issue Details (XML | Word | Printable)

Key: CORE-319
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Claudio Valderrama C.
Reporter: Claudio Valderrama C.
Votes: 0
Watchers: 0
Operations

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

DFW trashes RDB$RUNTIME

Created: 23/Mar/02 12:00 AM   Updated: 19/Jan/16 05:15 AM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 1.0.3

SF_ID: 533915
QA Status: No test


 Description  « Hide
SFID: 533915#
Submitted By: robocop

Firebird RC2, Firebird v1, any platform.

Here's an example that should be considered impossible
given the current rules that a trigger is owned only
by one table. But the problem is happening. I've
replaced control characters by asterisks:

SQL> set blob 5;
SQL> select rdb$runtime from rdb$relations where
rdb$relation_name = 'M' or rdb$relation_name = 'D';
For M:
*A***** CHECK_9
For D:
*B*C CHECK_9

It's illegal that two tables share the same trigger
generated by a check constraint! The bug is: any table
that's created gets appended the names of all
automatically created triggers in the db that exist
before it. Any table that's altered gets the names of
all automatically created triggers that exist, whether
they were created before or after the time that table
was created. Those triggers exist for views' with
check option, cascade RI and check constraints. As a
result of this, rdb$runtime is polluted with all those
trigger names that exist at the time a table is
created or altered. The net effect is neutralized by
the fact that later, MET_load_trigger() checks both
trigger name and relation name and hence, it doesn't
find (and doesn't load) the invalid entries.

I spotted the bug by reading the source code but took
a bit to realize the practical demonstration was
simple to produce.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.