New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Garbage vs indices/constraints [CORE405] #749
Comments
Commented by: @dyemanov I think this issue should be treated as a design pitfall. |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Won't Fix [ 2 ] SF_ID: 744175 => |
Commented by: @pcisar I think that while it's "as designed" pitfall, it's an issue that could really puzzle Firebird users, so it should be documented (it's not documented anywhere, as far as I know). I worry that if we'll close this issue, we will forget to do so. Hence I'd like suggest to reopen it and move it to Documnetation project, or better clone it to new task for Documentation project and close this one. What do you think? |
Commented by: @dyemanov I agree that it should be documented. Very few people use GC disabled in development, but they should be warned about the possible side effects anyway. |
Modified by: @pcisarWorkflow: jira [ 10429 ] => Firebird [ 14712 ] |
Modified by: @hvladstatus: Closed [ 6 ] => Reopened [ 4 ] assignee: Vlad Khorsun [ hvlad ] resolution: Won't Fix [ 2 ] => |
Modified by: @hvladstatus: Reopened [ 4 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 Beta 1 [ 10750 ] Fix Version: 3.0.4 [ 10863 ] |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: Done successfully Test Details: NOTE: 4.0 was not affected (no error occured during test) |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @dyemanov
SFID: 744175#
Submitted By: dimitr
If an index contains garbage and automatic GC
is disabled, then it's impossible to create unique
indices or PK/UK/FK constraints.
For example:
1) attach with isc_dpb_no_garbage_collect
2) insert some duplicate data
INSERT INTO T1 (F1) VALUES (1);
INSERT INTO T1 (F1) VALUES (1);
3) delete these rows
DELETE FROM T1;
4) create unique index
CREATE UNIQUE INDEX IDX1 ON T1 (F1);
You'll see "attempt to store duplicate value ..."
error message, which is incorrect in this case.
Since indices work outside transaction control, it
may be a initial design/implementation pitfall. It
appears the index creation and partner lookup
code never touches records and hence is unable
to determine which versions are actual at the
moment of index creation.
Commits: a16249f eaa1cff
====== Test Details ======
NOTE: 4.0 was not affected (no error occured during test)
The text was updated successfully, but these errors were encountered: