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-issue-importer opened this issue Mar 4, 2008 · 8 comments
Closed

Bugcheck 291 in DDL [CORE1770] #2195

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

Comments

@firebird-issue-importer
Copy link

@firebird-issue-importer firebird-issue-importer commented Mar 4, 2008

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 4, 2008

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 4, 2008

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 4, 2008

Modified by: @dyemanov

Version: 2.5 Initial [ 10260 ]

Version: 2.5 Alpha 1 [ 10224 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 17, 2008

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 17, 2008

Modified by: @AlexPeshkoff

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

resolution: Fixed [ 1 ]

Fix Version: 2.5 Alpha 1 [ 10224 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 6, 2009

Modified by: @AlexPeshkoff

Link: This issue relate to CORE2285 [ CORE2285 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2009

Modified by: @pcisar

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 19, 2016

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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants