Re: Simple fix for contrib/xml2

Lists: pgsql-hackers
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Simple fix for contrib/xml2
Date: 2010-02-28 19:25:57
Message-ID: 12315.1267385157@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I'm beginning to think nobody is going to step up and fix contrib/xml2,
so I had a look at it myself. It strikes me that there is a pretty
simple fix for it: just get rid of the attempt to manage libxml memory
via palloc, and don't do anything else. The implication of this will
be that if an error is thrown out of one of the libxml2 functions,
we'll leak whatever memory libxml2 was using for the current document
(for the life of the session). While this isn't great, it sure beats
crashing; and it seems like it might be about the appropriate level of
effort for a contrib module that's slated for destruction anyhow.
It looks to me like the only really probable elog cause within those
functions is out-of-memory, and even that wouldn't be very probable in
normal use. So sticking in PG_TRY/PG_CATCH logic would be a significant
increment in effort for only very marginal returns.

Comments, objections?

regards, tom lane


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Simple fix for contrib/xml2
Date: 2010-02-28 19:57:53
Message-ID: 201002281957.o1SJvrf17595@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> I'm beginning to think nobody is going to step up and fix contrib/xml2,
> so I had a look at it myself. It strikes me that there is a pretty
> simple fix for it: just get rid of the attempt to manage libxml memory
> via palloc, and don't do anything else. The implication of this will
> be that if an error is thrown out of one of the libxml2 functions,
> we'll leak whatever memory libxml2 was using for the current document
> (for the life of the session). While this isn't great, it sure beats
> crashing; and it seems like it might be about the appropriate level of
> effort for a contrib module that's slated for destruction anyhow.
> It looks to me like the only really probable elog cause within those
> functions is out-of-memory, and even that wouldn't be very probable in
> normal use. So sticking in PG_TRY/PG_CATCH logic would be a significant
> increment in effort for only very marginal returns.
>
> Comments, objections?

FYI, I created a web page of all the open xml items:

http://momjian.us/cgi-bin/pgsql/mbox?xml

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Simple fix for contrib/xml2
Date: 2010-02-28 20:08:20
Message-ID: 13146.1267387700@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> FYI, I created a web page of all the open xml items:
> http://momjian.us/cgi-bin/pgsql/mbox?xml

Oh, thanks, I was just about to go trawling through the archives to
verify all the reported failure cases really do get fixed this way.

I don't think you got em all though --- one I had on my list before
was bug #5079 ...

regards, tom lane


From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Simple fix for contrib/xml2
Date: 2010-03-03 04:28:03
Message-ID: 20100303042803.GA3075@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> I'm beginning to think nobody is going to step up and fix contrib/xml2,
> so I had a look at it myself.

Funny -- I was about to start working on this when the earthquake hit
here ... glad you got it :-)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support