BUG #4774: Bug with use execute+xml+xml_encode_special_chars

The following bug has been logged online:

Bug reference: 4774
Logged by: Nickolay
Email address: boks(at)doci(dot)in(dot)ua
PostgreSQL version: 8.3.5
Operating system: Linux app 2.6.18-92.1.1.el5.028stab057.2 #1 SMP Mon Jul
21 17:08:31 MSD 2008 x86_64 x86_64 x86_64 GNU/Linux
Description: Bug with use execute+xml+xml_encode_special_chars
Details:

Hello. It's definitely a bug:
Code:"
CREATE OR REPLACE FUNCTION bbb()
RETURNS xml AS
$BODY$
BEGIN
execute 'select public.xml_encode_special_chars(''1+1'')';
return '<v>Hello</v>';
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE STRICT SECURITY DEFINER
"

first execute answer: "<v>Hello</v>"
log file:"
LOG: команда: select bbb()
LOG: команда: SELECT format_type(oid,-1) as typname FROM pg_type
WHERE oid = 142
LOG: команда: SELECT CASE WHEN typbasetype=0 THEN oid else
typbasetype END AS basetype
FROM pg_type WHERE oid=142
"

second execute answer: "********** Error **********"
log file:"
LOG: команда: select bbb()
LOG: процесс сервера (PID 1483) was terminated by signal 11:
Segmentation fault
LOG: завершение любых других активных
серверных процессов
WARNING: закрытие подсоединения по причине
упада другого серверного процесса
ПОДРОБНОСТИ: The postmaster has commanded this server process to
roll back the current transaction and exit, because another server process
exited abnormally and possibly corrupted shared memory.
ПОДСКАЗКА: In a moment you should be able to reconnect to the
database and repeat your command.
WARNING: закрытие подсоединения по причине
упада другого серверного процесса
ПОДРОБНОСТИ: The postmaster has commanded this server process to
roll back the current transaction and exit, because another server process
exited abnormally and possibly corrupted shared memory.
ПОДСКАЗКА: In a moment you should be able to reconnect to the
database and repeat your command.
LOG: все серверные процессы завершены...
переинициализация
LOG: database system was interrupted; last known up at 2009-04-22 17:52:18
EEST
LOG: система баз данных была неправильно
остановлена; производится
автоматическое восстановление
LOG: запись с нулевой длинноц в 0/21FDE0E8
LOG: REDO (повторить) не требуется
LOG: checkpoint starting: shutdown immediate
LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s)
added, 0 removed, 0 recycled; write=0.000 s, sync=0.000 s, total=0.123 s
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
"

Interesting, functions:"
CREATE OR REPLACE FUNCTION bbb1()
RETURNS text AS
$BODY$
BEGIN
execute 'select public.xml_encode_special_chars(''1+1'')';
return '<v>Hello</v>';
END;
$BODY$
"
and
"
CREATE OR REPLACE FUNCTION bbb2()
RETURNS xml AS
$BODY$
BEGIN
-- execute 'select public.xml_encode_special_chars(''1+1'')';
return '<v>Hello</v>';
END;
$BODY$
" works correctly.

"Nickolay" <boks(at)doci(dot)in(dot)ua> writes:
> Hello. It's definitely a bug:

So what is public.xml_encode_special_chars()?

regards, tom lane

"Nickolay" <boks(at)doci(dot)in(dot)ua> writes:
> [ install contrib/xml2 and run this function twice: ]

> CREATE OR REPLACE FUNCTION bbb()
> RETURNS xml AS
> $BODY$
> BEGIN
> execute 'select public.xml_encode_special_chars(''1+1'')';
> return '<v>Hello</v>';
> END;
> $BODY$
> LANGUAGE 'plpgsql' VOLATILE STRICT SECURITY DEFINER

This seems to be another variant of the open problem with Perl-based
usage of libxml. contrib/xml2 is calling libxml without any knowledge
of the malloc hooks that adt/xml.c tries to put in. So we have first
a "bare" call of xmlEncodeSpecialChars(), which sets up various internal
libxml infrastructure using malloc allocation. Then xml_in() gets
invoked at the end of the plpgsql function call, and it causes the
libxml memory allocation hook functions to be changed. Then when you
repeat the function call, libxml is trying to manipulate
malloc-allocated structures using palloc functions, and kaboom.

I think this particular form of the problem would be fixed by the patch
I proposed a couple weeks ago, but I still don't have a lot of
confidence in that patch.

I'm beginning to think that changing the libxml allocation hooks
on-the-fly is simply wrong and can never be made to work. We should
either not change them at all (and perhaps tolerate some memory leakage)
or set them up once at backend start (and perhaps waste some cycles if
libxml is never used in the session). The big unknown with the latter
is that it might break expectations of third-party code such as Perl.
We don't know that Perl might not expect stuff it gets out of libxml
to live across transaction boundaries.

regards, tom lane

"Nickolay" <boks(at)doci(dot)in(dot)ua> writes:
> Description: Bug with use execute+xml+xml_encode_special_chars

There will be a patch for this in 8.4beta2. I'm not prepared to risk
back-patching it into 8.3 now, however; it's a nontrivial change.
Perhaps after it's gotten a bit of field testing in 8.4 ...

regards, tom lane