Tom Lane wrote:
Andrew Dunstan 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.
Andrew Dunstan 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 ugly.
Yup :-
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);
INS
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, ' b="oops"/>');
> SELECT * FROM xpath_table('id', 't', 'xpath_test',
> '/rowlist/row
Tom Lane 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:
> http://archives.postgresql.org/pgsql-committers/2009-05/msg00229.php
Alvaro Herrera 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 contrib is removed altogether
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:
/*
* N
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);
M Z 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 clobber data that
is o
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 wrote:
> On Wed, Feb 3, 2010 at 8:49 AM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >> On Mon, Feb 1, 2010 at
On Wed, Feb 3, 2010 at 8:49 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan 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 exagger
On Thu, Feb 4, 2010 at 10:51 PM, M Z 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,
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 modifie
Robert Haas escribió:
> On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan 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 succes
On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan 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 t
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 (pgsql-hackers@postgresql.or
On Mon, Feb 1, 2010 at 1:38 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 presumably in so
On Thu, Jan 28, 2010 at 5:41 PM, Tom Lane wrote:
> Andrew Dunstan 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 thi
Robert Haas escribió:
> On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus 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 ship
On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus 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 /contrib.
> 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 (pg
Andrew Dunstan 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 good idea.
Y
On Thu, Jan 28, 2010 at 4:18 PM, Andrew Dunstan 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
>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00198.p
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
documentat
25 matches
Mail list logo
