remove contrib/xml2
in [PgSql]
|
From: Robert Haas on 1 Feb 2010 20:44 On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > Robert Haas wrote: >> (2) add a very, very large warning that this will crash if you do >> almost anything with it. > > I think that's an exaggeration. Certain people are known to be using it > quite successfully. Hmm. Well, all I know is that the first thing I tried crashed the server. CREATE TABLE xpath_test (id integer NOT NULL, t xml); INSERT INTO xpath_test VALUES (1, '<doc><int>1</int></doc>'); SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int', 'true') as t(id int4); It doesn't crash if you change the type of t from xml to text; instead you get a warning about some sort of memory allocation problem. DROP TABLE xpath_test; CREATE TABLE xpath_test (id integer NOT NULL, t text); INSERT INTO xpath_test VALUES (1, '<doc><int>1</int></doc>'); SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int', 'true') as t(id int4); yields: WARNING: problem in alloc set ExprContext: bogus aset link in block 0x14645e0, chunk 0x14648b8 And then there's this (see also bug #5285): DELETE FROM xpath_test; INSERT INTO xpath_test VALUES (1, '<rowlist><row a="1"/><row a="2" b="oops"/></rowlist>'); SELECT * FROM xpath_table('id', 't', 'xpath_test', '/rowlist/row/@a|/rowlist/row/@b', 'true') as t(id int4, a text, b text); which yields an answer that is, at least, extremely surprising, if not flat-out wrong: id | a | b ----+---+------ 1 | 1 | oops 1 | 2 | (2 rows) Bugs #4953 and #5079 can also be reproduced in CVS HEAD. Both crash the server. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 3 Feb 2010 08:49 Robert Haas escribi�: > On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > > Robert Haas wrote: > >> (2) add a very, very large warning that this will crash if you do > >> almost anything with it. > > > > I think that's an exaggeration. Certain people are known to be using it > > quite successfully. > > Hmm. Well, all I know is that the first thing I tried crashed the server. > > CREATE TABLE xpath_test (id integer NOT NULL, t xml); > INSERT INTO xpath_test VALUES (1, '<doc><int>1</int></doc>'); > SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int', 'true') > as t(id int4); This trivial patch lingering on my system fixes this crasher (this is for the 8.3 branch). It makes the "problem in alloc set ExprContext" warning show up instead. There are still lotsa other holes, but hey, this is a start ... Index: contrib/xml2/xpath.c =================================================================== RCS file: /home/alvherre/Code/cvs/pgsql/contrib/xml2/xpath.c,v retrieving revision 1.16.2.1 diff -c -p -r1.16.2.1 xpath.c *** contrib/xml2/xpath.c 26 Mar 2008 01:19:11 -0000 1.16.2.1 --- contrib/xml2/xpath.c 27 Jan 2010 15:30:56 -0000 *************** xpath_table(PG_FUNCTION_ARGS) *** 793,798 **** --- 793,801 ---- */ pgxml_parser_init(); + PG_TRY(); + { + /* For each row i.e. document returned from SPI */ for (i = 0; i < proc; i++) { *************** xpath_table(PG_FUNCTION_ARGS) *** 929,934 **** --- 932,944 ---- if (xmldoc) pfree(xmldoc); } + } + PG_CATCH(); + { + xmlCleanupParser(); + PG_RE_THROW(); + } + PG_END_TRY(); xmlCleanupParser(); /* Needed to flag completeness in 7.3.1. 7.4 defines it as a no-op. */ -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: M Z on 4 Feb 2010 22:51 I did some tests followed Robert's test cases on both postgresql 8.4.2-0ubu and 8.3.8-1, OS: Ubuntu Karmic. 1) 1st test case, it doesn't crash on 8.3.8 but crash on 8.4.2; 2) 2nd test case, both 8.3.8 and 8.4.2 are fine, and no warning (different from Robert's test?); 3) 3rd test case (and modified test case for 8.3.8), both 8.3.8 and 8.4.2 are not correct, same with Robert's test (8.5 beta?); ************************************* 1st test case: ================== 8.3.8 ================== conifer=# CREATE TABLE xpath_test (id integer NOT NULL, t xml); CREATE TABLE conifer=# INSERT INTO xpath_test VALUES (1, '<doc><int>1</int></doc>'); INSERT 0 1 conifer=# SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int', 'true') as t(id int4); id ---- 1 (1 row) ================== 8.4.2 ================== conifer=# CREATE TABLE xpath_test (id integer NOT NULL, t xml); CREATE TABLE conifer=# INSERT INTO xpath_test VALUES (1, '<doc><int>1</int></doc>'); INSERT 0 1 conifer=# SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int', 'true') as t(id int4); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !> ************************************* ************************************* 2nd test case ================== 8.3.8 and 8.4.2 ================== conifer=# CREATE TABLE xpath_test (id integer NOT NULL, t text); CREATE TABLE conifer=# INSERT INTO xpath_test VALUES (1, '<doc><int>1</int></doc>'); INSERT 0 1 conifer=# SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int', 'true') as t(id int4); id ---- 1 (1 row) ************************************* ************************************* 3rd test case ================== 8.3.8 and 8.4.2 ================== conifer=# CREATE TABLE xpath_test (id integer NOT NULL, t text); CREATE TABLE conifer=# INSERT INTO xpath_test VALUES (1, '<rowlist><row a="1"/><row a="2" b="oops"/></rowlist>'); INSERT 0 1 conifer=# SELECT * FROM xpath_table('id', 't', 'xpath_test', '/rowlist/row/@a|/rowlist/row/@b', 'true') as t(id int4, a text, b text); id | a | b ----+---+------ 1 | 1 | oops 1 | 2 | (2 rows) ================== 8.3.8 (modified 3rd test case, because 8.3.8 won't crash using xml) ================== conifer=# CREATE TABLE xpath_test (id integer NOT NULL, t xml); CREATE TABLE conifer=# INSERT INTO xpath_test VALUES (1, '<rowlist><row a="1"/><row a="2" b="oops"/></rowlist>'); INSERT 0 1 conifer=# SELECT * FROM xpath_table('id', 't', 'xpath_test', '/rowlist/row/@a|/rowlist/row/@b', 'true') as t(id int4, a text, b text); id | a | b ----+---+------ 1 | 1 | oops 1 | 2 | (2 rows) ************************************* For 1st test case, not sure if some paths applied to 8.3 haven't been applied to 8.4, or other reasons cause the difference between 8.3.8 and 8.4.2. Any ideas or comments? Thank you, M Z On Mon, Feb 1, 2010 at 8:44 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan <andrew(a)dunslane.net> > wrote: > > Robert Haas wrote: > >> (2) add a very, very large warning that this will crash if you do > >> almost anything with it. > > > > I think that's an exaggeration. Certain people are known to be using it > > quite successfully. > > Hmm. Well, all I know is that the first thing I tried crashed the server. > > CREATE TABLE xpath_test (id integer NOT NULL, t xml); > INSERT INTO xpath_test VALUES (1, '<doc><int>1</int></doc>'); > SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int', 'true') > as t(id int4); > > It doesn't crash if you change the type of t from xml to text; instead > you get a warning about some sort of memory allocation problem. > > DROP TABLE xpath_test; > CREATE TABLE xpath_test (id integer NOT NULL, t text); > INSERT INTO xpath_test VALUES (1, '<doc><int>1</int></doc>'); > SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int', 'true') > as t(id int4); > > yields: > > WARNING: problem in alloc set ExprContext: bogus aset link in block > 0x14645e0, chunk 0x14648b8 > > And then there's this (see also bug #5285): > > DELETE FROM xpath_test; > INSERT INTO xpath_test VALUES (1, '<rowlist><row a="1"/><row a="2" > b="oops"/></rowlist>'); > SELECT * FROM xpath_table('id', 't', 'xpath_test', > '/rowlist/row/@a|/rowlist/row/@b', 'true') as t(id int4, a text, b > text); > > which yields an answer that is, at least, extremely surprising, if not > flat-out wrong: > > id | a | b > ----+---+------ > 1 | 1 | oops > 1 | 2 | > (2 rows) > > Bugs #4953 and #5079 can also be reproduced in CVS HEAD. Both crash the > server. > > ...Robert > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
From: Robert Haas on 5 Feb 2010 13:45 On Wed, Feb 3, 2010 at 8:49 AM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > Robert Haas escribió: >> On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: >> > Robert Haas wrote: >> >> (2) add a very, very large warning that this will crash if you do >> >> almost anything with it. >> > >> > I think that's an exaggeration. Certain people are known to be using it >> > quite successfully. >> >> Hmm. Well, all I know is that the first thing I tried crashed the server. >> >> CREATE TABLE xpath_test (id integer NOT NULL, t xml); >> INSERT INTO xpath_test VALUES (1, '<doc><int>1</int></doc>'); >> SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int', 'true') >> as t(id int4); > > This trivial patch lingering on my system fixes this crasher (this is > for the 8.3 branch). It makes the "problem in alloc set ExprContext" > warning show up instead. > > There are still lotsa other holes, but hey, this is a start ... Interestingly M Z found he couldn't reproduce this crash on 8.3. Can you? If so, +1 for applying this and backpatching it as far as make sense. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 5 Feb 2010 13:42 On Thu, Feb 4, 2010 at 10:51 PM, M Z <jm80008(a)gmail.com> wrote: > I did some tests followed Robert's test cases on both postgresql 8.4.2-0ubu > and 8.3.8-1, OS: Ubuntu Karmic. > > 1) 1st test case, it doesn't crash on 8.3.8 but crash on 8.4.2; Interesting. So, that's a regression of some kind. > 2) 2nd test case, both 8.3.8 and 8.4.2 are fine, and no warning (different > from Robert's test?); I built with --enable-debug and --enable-cassert, which might be relevant. > 3) 3rd test case (and modified test case for 8.3.8), both 8.3.8 and 8.4.2 > are not correct, same with Robert's test (8.5 beta?); As I think about that further, it might not be a bug - how is the processor supposed to know what we expect to happen? But then, I don't really know how this is supposed to work. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: plperl compiler warning Next: [HACKERS] returning array in a field together with other types |