Dirty RDB$PAGES after an error after phase 3 of create_relation
---------------------------------------------------------------
Key: CORE-5677
URL: http://tracker.firebirdsql.org/browse/CORE-5677
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 4.0 Alpha 1, 3.0.2, 2.5.7, 3.0.1, 2.5.6, 3.0.0, 4.0
Initial
Environment: Ubuntu x86_64
Reporter: Roman Simakov
In case of error after phase 3 of create_relation in dfw the engine have filled
RDB$PAGES in system transaction. Changes of RDB$RELATIONS and RDB$DATABASE are
doing in user transaction and they rolled back. As result we have a couple of
records in RDB$PAGES. Later if some attachment will scan pages it creates an
object jrd_rel in att_relations and marks it by flag REL_check_existance and
later REL_deleted.
If we will try to create a table in this attachment we can do it. But at least
we will have duplicated records in RDB$PAGES for the relation. Then if we will
try to create an index for that table MET_lookup_relation_id will check
REL_deleted and returns NULL. Index creation will fails.
Reconnect can helps but duplicates of RDB$PAGES is not good in any case.
Here is a scenario to reproduce it by 2 terminals (1: and 2:) on Classic
arcitecture:
2: create database '/tmp/d.fdb';
2: set transaction read committed;
1: gdb --args ./isql /tmp/d.fdb
1: r
1: Ctrl+C
1: break check_not_null if (phase==3)
1: c
1: create table tn(i integer);
1: insert into tn values(NULL);
1: commit;
1: set autoddl off;
1: set transaction read committed;
1: create table terr(i integer);
1: alter table tn alter i set not null;
1: commit;
1: will break in breakpoint
2: select * from rdb$pages; // to force write RDB$PAGES via AST
1: c
1: ERROR: Cannot make field I of table TN NOT NULL because there are NULLs
present
1+2: Ctrl+D to exit
Now we can connect to the database and check:
SQL> select * from rdb$pages where rdb$relation_id=129;
RDB$PAGE_NUMBER RDB$RELATION_ID RDB$PAGE_SEQUENCE RDB$PAGE_TYPE
=============== =============== ================= =============
186 129 0 4
187 129 0 6
SQL> select * from rdb$relations where rdb$relation_id=129;
SQL> select rdb$relation_id from rdb$database;
RDB$RELATION_ID
===============
129
The idea of fix is to cleanup RDB$PAGES and release physically located pages at
phase 0 of create_relation. I'll prepare PR soon.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
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
