Skip to content
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

Bugcheck 291 in DDL [CORE1770] #2195

Closed
firebird-automations opened this issue Mar 4, 2008 · 8 comments
Closed

Bugcheck 291 in DDL [CORE1770] #2195

firebird-automations opened this issue Mar 4, 2008 · 8 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @AlexPeshkoff

Relate to CORE2285

This is actually very old bug, but it started to actively show itself only in 2.5 - most possible due to more places when threads can run together in the engine. I will describe it on a simple and not widely used today sample, but it obviously can happen in other cases too.

Imagine some system relation (for example rdb$database) is modified in user transaction (this really happens in GPRE-preprocessed programs to set database properties). Transaction is committed, and there is an old version of the record on the disk. Right after it CREATE TABLE is issued, which modifies same relation rdb$database in system transaction. System transaction always uses update_in_placed() to update a record. But during it another thread (on SS this is GC thread, but it can easily be any regular attachment reading rdb$database) removes old unused version of the record. At this moment system transaction fails with bugcheck(291) - no record version found.

Commits: 4df924e 8a5e606 d3ec37b

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

I have a short and working fix for this issue, but it is really hack. The correct fix should be to separate two "magics" of system transaction - dirty read/write and always update_in_place().

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Version: 2.5 Initial [ 10260 ]

Version: 2.5 Alpha 1 [ 10224 ] =>

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Historically we have 2 ways to detect is current transaction system or not - fixed number 0 and flag TRA_system. Initially I was going to use only TRA_system flag and separate in into 2 logical features - dirty access to data and all updates in place. But after reviewing the code it was noticed, that in some places (mainly in the ODS, where transaction number is stored in record version), there is no other information about transaction except it's number. Therefore I had to go another way - and one of possible was modifying of system data in user transation at defreed work phase. Should notice, that in general it's not a crime - a lot of such modifications are performed in dyn*.epp.

Most of changes in deferred work are performed against an object, which name matches dfw_name, i.e. this is an object, directly related with transaction for which we perform deferred work (or closely related objects - like segments of index). The only place where dirty write to system tables seemed to me important is adding new files to database. Luckily, it was always done exclusively. In 2 places I've found that it's required to provide dirty reads in DFW - it's relation ID generation (implemented in metadata cache, i.e. in transaction 0) and access to RDB$FIELDS when creating index (needed to support a kind of hack in gbak, making it possible to use PLAN in procedures). In the last case I had to separate FOR cycle in dfw.epp to keep read access from system transaction, but modification - from user one.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5 Alpha 1 [ 10224 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Link: This issue relate to CORE2285 [ CORE2285 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants