trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Birdsall <dave.birds...@esgyn.com>
Subject Heads up on default character set impact
Date Thu, 03 Mar 2016 18:37:24 GMT
Hi,



This morning I debugged a problem on a test cluster where UPDATE STATISTICS
was failing with an assertion error (error 2006).



Turns out the cause was:



1.       The default character set of the instance had been set in the
system DEFAULTS table to UTF8. (If nothing is set, we default to ISO
8859/1.)

2.       The table in question already had statistics.

3.       UPDATE STATISTICS uses a query to read the existing histograms,
and has a cast expression in it (cast(read_time as char(19)); here
read_time is a TIMESTAMP(0) column in the SB_HISTOGRAMS table. It was using
a char[20] stack variable to receive the result of this read. Because the
default character set was UTF8, Trafodion assumed the host variable was at
least 19 **characters** long, that is, 76 bytes. So, we got a buffer
overrun. And because the stars were aligned right, the buffer overrun
overwrote another stack variable which was later tested in the assertion.



I bring this up to the development community because much of our code does
queries under the covers. The issue is, be careful when doing casts to CHAR
data types. Allocate sufficient space in your target buffers for them, and
be sure you know what character set you are getting. In this example, I
plan to fix the problem by rewriting the cast to “cast (read_time as
char(19) character set iso88591)”. What’s right in your situation may
differ.



While I’m fixing this, I’ll look for other examples in the ustats code
where this might be an issue. But you may want to check other areas, for
example the DDL code or any UDFs you are writing that contain SQL code.



Dave

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message