DB2 FOR LUW / DB2FORLUW / A50 - DB2

Concurrency issues can arise if updates to entries are committed 
before other queries fetch data with CS isolation in columnar 
organized tables. This results in rows that that originally 
matched the query predicates being returned with their updated 
values when they should not have been selected. 
 
Example: Table t1 (col1 int not null, col2 int not null) with 
value (8,1) 
 
1)    Session 1 executes an update to an entry( (8,1) becomes 
(9,1) ) but does not commit the work: 
UPDATE t1 SET COL1 = 9 WHERE COL1 = 8 
 
2)    Session 2 executes a select query: 
SELECT * FROM t1 WHERE col1=8 with CS 
DB2 returns an FETCH-ISCAN access plan.  The runtime has not 
started the ISCAN operation yet. 
 
3)    Session 1 commits the work for the UPDATE, which means 
that we should not have any entries where COL1 = 8 (i.e. the 
only value in t1 is (9,1) ). 
 
4)    Session 2 completes its execution of the FAST FETCH-ISCAN 
plan and returns (9,1) which is not expected. 
 
The ISCAN operator returns pseudo deleted keys, which have rows 
that have COL1=8 (because the UPDATE has not been committed 
yet).

**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to Db2 10.5 Fix Pack 9 or higher                     * 
****************************************************************

First fixed in Db2 10.5 Fix Pack 9

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

05.05.2017
29.09.2017
12.10.2017

9.0.