Issue Details (XML | Word | Printable)

Key: CORE-2440
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Jiri Cincura
Votes: 0
Watchers: 2

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

Restoring DB with computed index on computed field provides wrong index and wrong select results

Created: 23/Apr/09 12:00 AM   Updated: 06/Mar/19 08:00 AM
Component/s: Engine, GBAK
Affects Version/s: 2.5 Beta 1
Fix Version/s: 4.0 Beta 1, 2.5.9, 3.0.5

File Attachments: 1. File bak.bak (206 kB)

Environment: SuperClassis, Linux 32b
Issue Links:

QA Status: Covered by another test(s)
Test Details:
See test for CORE-5118.
Bug was fixed, ticket CORE-2440 can be closed.

Sub-Tasks  All   Open   

 Description  « Hide
Attached is backup of database. If you restore it and run "select id from prislusenstvi order by upper(title)" you get wrong result. If you look at the index IDX_PRISLUSENSTVI_UPPER_TITLE it's wrong. After recreating the index, everything is OK.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Jiri Cincura added a comment - 23/Apr/09 12:17 AM
Please keep the ticket restricted, the database isn't for public.

Vlad Khorsun added a comment - 04/May/09 04:26 PM
At restore, indices are activated before the commit of transaction within which computed fields are updated with its BLR. Therefore expression index not see correct BLR of computed field on which index is depends. As result such expression index is built using empty key values.

Fix is to commit computed fields transaction before activation of indices.

Dmitry Yemanov added a comment - 08/May/09 11:51 AM
The ticket is reopened because:
1) It doesn't solve the reported issue when a database is restored *without* the -verbose switch.
2) It breaks restore for any database that has user-defined plans embedded into procedures/triggers and the restore is performed *with* the -verbose switch.