By the way, I wrote a JIRA to cover the UPDATE STATISTICS issue: https://issues.apache.org/jira/browse/TRAFODION-1871
*From:* Dave Birdsall [mailto:[email protected]] *Sent:* Thursday, March 3, 2016 10:37 AM *To:* '[email protected]' < [email protected]> *Subject:* Heads up on default character set impact 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
