Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
... The reason for that behavior is that xpath_table runs through
the XPATH_NODESET results generated by the various XPaths and dumps the
k'th one of each into the k'th output row generated for the current
I believe I have fixed all the reported crashes in contrib/xml2.
However there is still this issue pointed out by Robert:
CREATE TABLE xpath_test (id integer NOT NULL, t xml);
INSERT INTO xpath_test VALUES (1, 'rowlistrow a=1/row a=2
b=oops//rowlist');
SELECT * FROM xpath_table('id', 't',
Tom Lane wrote:
I believe I have fixed all the reported crashes in contrib/xml2.
Yay! Well done! That at least removes any possibly urgency about
removing the module.
However there is still this issue pointed out by Robert:
CREATE TABLE xpath_test (id integer NOT NULL, t xml);
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
... The reason for that behavior is that xpath_table runs through
the XPATH_NODESET results generated by the various XPaths and dumps the
k'th one of each into the k'th output row generated for the current
input row.
Damn that's
M Z escribió:
Hi Alvaro,
I followed your instruction but put the patch on 8.4.2 as I found it
crashes. It looks like the server still crash in the same way. Can you and
anyone give me some ideas how to fix this bug?
See src/backend/utils/adt/xml.c. Note the comment at the top:
/*
* Notes
Alvaro Herrera alvhe...@commandprompt.com writes:
Then if you look at xpath.c in contrib/xml2 you notice that it's doing
exactly the thing that the core module says it's unreliable: using
palloc and friends in xmlMemSetup. So to fix the bug what's needed is
that the xmlMemSetup call in
Tom Lane t...@sss.pgh.pa.us writes:
FWIW, the core xml code seems to have been pretty stable since we gave
up on trying to redirect libxml's memory allocations to palloc.
So what you basically need to do to xpath.c is something like this:
Hi Alvaro,
I followed your instruction but put the patch on 8.4.2 as I found it
crashes. It looks like the server still crash in the same way. Can you and
anyone give me some ideas how to fix this bug?
==
conifer=# CREATE TABLE xpath_test (id integer NOT NULL, t xml);
The thing is, why it doesn't crash on 8.3.8 but crash on 8.4.2? Any idea? A
patch was applied to 8.3 but not to 8.4.2?
Thanks,
M Z
On Fri, Feb 5, 2010 at 1:45 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 3, 2010 at 8:49 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert
M Z jm80...@gmail.com writes:
The thing is, why it doesn't crash on 8.3.8 but crash on 8.4.2? Any idea?
Pure luck. Memory-clobber bugs like these are notoriously
nondeterministic. Any minor, logically unrelated change could make them
visible or not visible, because the clobber happens to
On Thu, Feb 4, 2010 at 10:51 PM, M Z jm80...@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)
On Wed, Feb 3, 2010 at 8:49 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan and...@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 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
Robert Haas escribió:
On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan and...@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
On Thu, Jan 28, 2010 at 5:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I think we need to either (1) fix the bugs and update the
documentation to remove the statement that this will be removed or (2)
actually remove it.
I agree it's
Robert Haas robertmh...@gmail.com writes:
My feeling is that if it's as flakey and unreliable as it currently
is, we shouldn't ship it. Removing it from CVS doesn't mean you
can't use this any more; this is open source. It just means people
will have to go and get an old copy out of CVS and
On Mon, Feb 1, 2010 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
My feeling is that if it's as flakey and unreliable as it currently
is, we shouldn't ship it. Removing it from CVS doesn't mean you
can't use this any more; this is open source. It
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list
On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan and...@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
Robert Haas wrote:
There has been some more discussion lately of problems caused by contrib/xml2.
http://archives.postgresql.org/pgsql-bugs/2010-01/msg00251.php
http://archives.postgresql.org/pgsql-bugs/2010-01/msg00198.php
I think we need to either (1) fix the bugs and update the
On Thu, Jan 28, 2010 at 4:18 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
There has been some more discussion lately of problems caused by
contrib/xml2.
http://archives.postgresql.org/pgsql-bugs/2010-01/msg00251.php
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I think we need to either (1) fix the bugs and update the
documentation to remove the statement that this will be removed or (2)
actually remove it.
I agree it's a mess but I don't think just abandoning the functionality
is a
Yeah, we can't really remove it until we have a plausible substitute for
the xpath_table functionality. This is in the TODO list ...
What about moving it to pgfoundry?
I'm really not keen on shipping known-broken stuff in /contrib.
--Josh Berkus
--
Sent via pgsql-hackers mailing list
On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus j...@agliodbs.com wrote:
Yeah, we can't really remove it until we have a plausible substitute for
the xpath_table functionality. This is in the TODO list ...
What about moving it to pgfoundry?
I'm really not keen on shipping known-broken stuff in
Robert Haas escribió:
On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus j...@agliodbs.com wrote:
Yeah, we can't really remove it until we have a plausible substitute for
the xpath_table functionality. This is in the TODO list ...
What about moving it to pgfoundry?
I'm really not keen on
25 matches
Mail list logo
