"Nickolay" <b...@doci.in.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
