LIST() may overwrite last part of output with zero characters [CORE3262] #3630
Submitted by: @paulvink
LIST overwrites the last portion of the result with zero characters when the length gets above 4030:
create table vc (s varchar(8000));
insert into vc values (cast('A' as char(4000)) || 'B');
update vc set s = (cast('A' as char(5000)) || 'B');
To test if it's not the position function screwing up:
with q (l) as (select reverse(list(s)) from vc)
It's still B that's not found, even though it ought to be at position 1 now.
with q (l) as (select list(s) from vc)
Testing with different lengths of s reveals:
If the table contains two records, the position of the (first) null character is 8131,
With UTF8, the behaviour is slightly different: here, already char_length(list(s))
Three last remarks:
1) With CHAR or BLOB SUB_TYPE TEXT, the same errors happen
2) In PSQL, these errors do NOT occur. No zeroes are inserted and even the
3) In 2.5, these errors don't occur at all (in as much as I tested them).
The text was updated successfully, but these errors were encountered:
Commented by: @paulvink
With 22.214.171.12470 (Win32 Superserver), everything works fine.
The original tests were made on 126.96.36.19985.0-2.fc11 (x86-64 Classic server on Fedora 11).
To make sure it wasn't the package or 32 vs. 64 bit, I uninstalled 2.1.4 from the above Windows box and installed a fresh 188.8.131.5285 32-bits Superserver.
All the tests were run on freshly created Dialect 3 databases, without any "fancy" settings.
So, *something* must have changed (for the better) between builds 18185 and 18370.
I'll try a 2.1.0 tomorrow.
This kind of bug can go unnoticed for a long time, because as soon as you have multiple records, the position at which the \0 characters start increases rapidly.
Commented by: @paulvink
> And who will be the author of the fix in the release notes? ;-)
Ideally, we should know what caused this and what fixed it.
Just one suggestion: The threshold of roughly 4K around which things start to go wrong made me think of CORE3228 (RIGHT),
CORE3228 was fixed for 2.1.4 and 2.5.1. The fact that it existed in 2.5.0 may plead against it having the same cause as this one,
Another thing that changed between 2.1.3 and 2.1.4 is that LIST()'s second parameter may now be any string expression.
Commented by: @dyemanov
It's a side effect of the commit by 02-Sep-2009 (Backported fix for CORE1658) and 24-Sep-2009 (Backport fixes from HEAD related to CORE1658), in particular the changes regarding the location of the BLB_close() call inside EVL_group() and handling the BLB_closed flag in BLB_open(). Together they solve this issue.