This APAR fixes a memory corruption that is caused by a memory
alignment problem in the internal structures that deal with the
tablequeues logic.
A tablequeue is the access plan functionality that allows for
the sending of row data in between subsections of the plan. As
such, you can only get an access plan that features a tablequeue
for an instance configured with the data partitioning facility
(DPF), OR, if the instance is configured for intra-partition
parallelism (the dbm cfg setting of INTRA_PARALLEL is turned
on). Otherwise, this problem cannot be encountered.
In addition, the conditions to potentially hit the problem are:
- there is a tablequeue in the access plan that contains
DECFLOAT(34) columns in the tablequeue row.
- a memory allocation during the query initialization happens by
chance to have a certain alignment. There is no way to control
this alignment, however it's noted that it's somewhat rare to
achieve the alignment necessary to result in this problem.
- the problem is more likely to occur for, but not limited to,
sorted/merging tablequeues
The APAR will fix the alignment of the allocation and remove the
potential to encounter the memory corruption.
Since this defect is about a memory corruption, it means that
the end symptom may not be clearly defined since it depends on
what things get overwritten by the corruption. Typically for
this defect, we have seen crashes when an agent has read a row
from the tablequeue, but the row data does not make sense so the
subsequent handling of the row fails. An example stack that we
have seen for this is the following, where an insert failed
because it read the bad data from the corrupted tablequeue, but
there is likely other potential traps that could happen:
sqldValidateData + 0xAD0
sqldFastFormatFixedVar + 0x540
sqldFastFormat + 0x5C
sqldRowInsert + 0xC14
sqlrinsr + 0x108 |
