If there is a session doing a query using dirty read isolation
level on a table > 500 pages, the server can do a light scan of
the table. When the server does this, if there is an open
in-place alter on the table, there's a timing issue, where if
some DML happens to the table which causes a new page to be used
(so would increase npused), the light scan can mistakenly read
that last page/new page solely from disk (and not use look aside
to see the most recent modified version of the page from the
buffer pool). If this happens, it can cause all sorts of
various rowalter failures depending on the type of in-place
alter that exists on the table, and the old data that could
exist on the page from disk. To run into problems this old page
on disk would need to be of type PG_DATA and would have to have
non-deleted slots left over on the page for the server code to
try and examine.
The assert failure would look something like this:
17:26:59 IBM Informix Dynamic Server Version 12.10.FC5
Software Serial Number RDS#N000000
17:26:59 Assert Failed: rowalter: PTOCOPYVC: collen (0x100) >
max_vc_len (0x33) (cmpoff: 0x14, uncmpoff 0x14
17:26:59 Who: Session(63, informix@machine, 23369, 0x666eec70)
Thread(93, sqlexec, 666ac1e8, 12)
File: rssupp.c Line: 3701
17:26:59 Results: altering older version row to latest version
failed
Stack:
afstack
afhandler
affail_interface
rowalter
decompress_row *** note on some platforms this function
may or may not be visible in the stack due to function in-lining
***
rsseqscan_read
fmseqscan_read
readseq_batch
gettupl
scan_next
getrow
fetchrow
exfetch
sql_nfetch
sq_nfetch
sqmain
spawn_thread
th_init_initgls
startup
Then from onstat -g ses output in the AF file the session would
be using dirty read isolation:
sqscb info
scb sqscb optofc pdqpriority
optcompind directives
34ed163d8 37b91a028 0 0 2
1
Sess SQL Current Iso Lock SQL
ISAM F.E.
Id Stmt type Database Lvl Mode ERR
ERR Vers Explain
1368452 SELECT dbname DR Wait 90 0 0
9.28 Off
And in the onstat -g ses output there's no direct indication of
a light scan happening, but the presence of these memory types
in the session pool would indicate a light scan in use:
Memory pools count 2
name class addr totalsize freesize
#allocfrag #freefrag
1368452 V 36eba1040 716800 70368 1411
40
1368452*O0 V 376475040 4096 768 1
1
name free used name free
used
fragman 0 1160 light_scan 0
144
lt_scan_rbuff 0 208 lt_scan_bufs 0
64
udr 0 8704 rsam_seqscan 0
176
(light_scan, lt_scan_rbuf, and lt_scan_bufs)
Not included in the af file you can see the light scan for sure
using onstat -g scn |
