Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 31. Oktober 2007 schrieb Sheikh Amjad:
Following test case is crashing the postgresql-8.3-beta
Btw., I didn't forget this, but I haven't found an extended period of quiet
time to develop a proper solution.
I fixed it a few days ago...
Am Mittwoch, 31. Oktober 2007 schrieb Sheikh Amjad:
Following test case is crashing the postgresql-8.3-beta
SELECT XMLELEMENT
( NAME Program,
XMLAGG
( XMLELEMENT
( NAME Student, s.name::xml )
)
) AS Registered Student
Peter Eisentraut [EMAIL PROTECTED] writes:
Heikki Linnakangas wrote:
It still feels unsafe to call ExecEvalExpr while holding on to xml
structs. It means that it's not safe for external modules to use
libxml2 and call xmlMemSetup or xmlSetGenericErrorFunc themselves.
Well yeah, they
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
So my current theory is:
In xmlelement(), we use ExecEvalExpr(), which in turn calls xml_parse.
xml_parse calls xmlCleanupParser(). But when we call ExecEvalExpr(),
we're in the middle of constructing an xml buffer, so calling
Heikki Linnakangas [EMAIL PROTECTED] writes:
Hmm. There's the check sizeof(char) == sizeof(xmlChar), which in fact should
be evaluated at compile time (should that actually be an #error?).
sizeof() isn't expanded by cpp (and cannot be due to cross-compilation) so it
can't be a #error. It
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think that (1) we need a call to xml_init here, and hence also a
PG_TRY block;
xml_init doesn't actually do anything that would need to be free'd in
case of error. But yeah, it does seem like a good idea to free the text
Heikki Linnakangas wrote:
It still feels unsafe to call ExecEvalExpr while holding on to xml
structs. It means that it's not safe for external modules to use
libxml2 and call xmlMemSetup or xmlSetGenericErrorFunc themselves.
Well yeah, they shouldn't do that. I don't think we want to support
Tom Lane wrote:
No, your first theory is closer to the mark. What is happening is
that xmlelement neglects to call xml_init, therefore the various
stuff allocated by libxml is allocated using malloc(). Then
xml_parse is called, and it *does* do xml_init(), which calls
xmlMemSetup. Then
Tom Lane wrote:
Well, xml_init calls xmlInitParser() which needs to be cleaned up.
But since xmlelement doesn't need that, maybe we should factor it
out of xml_init.
That could help.
As for the try/catch blocks instead of relying on memory context
cleanup, I'm not entirely sure if that's
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
The note
at line 27ff of xml.c implies that libxml keeps static pointers to
allocated things that it thinks will survive indefinitely, so we
may have to have these. I'm suspicious whether xmlelement doesn't
have a problem if the
Sheikh Amjad wrote:
Following test case is crashing the postgresql-8.3-beta
create schema st;
CREATE TABLE ST.STUDENT(
STUDENT_ID VARCHAR2(10),
NAME VARCHAR(50) NOT NULL,
NIC CHAR(11),
DOB DATE NOT NULL,
GENDER CHAR(1) NOT NULL,
MAR_STAT
I wrote:
I was able to reproduce this after replacing those VARCHAR2's with
VARCHAR. I added some debugging elog's (attached), and it looks like
libxml2 is trying xml_pfree a pointer we never gave it in any of the
alloc functions. Log attached, last xml_pfree crashes and it's the first
time
Heikki Linnakangas [EMAIL PROTECTED] writes:
So my current theory is:
In xmlelement(), we use ExecEvalExpr(), which in turn calls xml_parse.
xml_parse calls xmlCleanupParser(). But when we call ExecEvalExpr(),
we're in the middle of constructing an xml buffer, so calling
13 matches
Mail list logo
