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 a
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 "Registe
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
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 probl
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'
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
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 suppor
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 "te
"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.
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
x
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
> xmlCleanupB
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 853
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
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 CHAR(1) NOT NULL,
14 matches
Mail list logo
