The following bug has been logged online:
Bug reference: 1723
Logged by: Dave Chapeskie
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system: FreeBSD 5.x
Description: array_cat() bug when passed empty array
Details:
I believe this bug still exists in the latest 8.0.x but
have not tested that version, just looked at the code.
array_cat() has a bug when passed an empty array. The
code attempts to optimise/short-circuit this case and
returns a pointer to the non-empty argument. This is
bad/wrong. Especially when used in a construct like:
foo := foo || <some_array>
since after array_cat() returns exec_assign_value()
will pfree() 'foo' and then attempt to assign the now
invalid result that points to 'foo'.
Turning on assertion checks (which turns on memory
checks) catches this. Here is a simple example:
create or replace function array_test (text[],text[])
returns text[] as '
declare
tmp text[];
begin
tmp := $1;
tmp := tmp || $2;
return tmp;
end'
language plpgsql
stable;
select array_test(array['foo','bar'],'{x}');
select array_test(array['foo','bar'],'{}');
The first call to array_test() returns
{foo,bar,x}
as expected. With debuging on the second call returns:
ERROR: out of memory
DETAIL: Failed on request of size 1065320319.
CONTEXT: PL/pgSQL function "array_test" while casting return value to
function's return type
Note 1065320319 = 0x3F7F7F7F and with debugging pfree'd
memory is filled with 0x74 bytes. The top 0x4000000
got cleared because the top bits of the length field
are flag bits. I've also seen the error say
"Failed on request of size 2139062147.".
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
