Skip site navigation (1) Skip section navigation (2)

Re: contrib/xml2 vs core xml in 8.3

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: contrib/xml2 vs core xml in 8.3
Date: 2010-03-01 00:08:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Feb 28, 2010 at 06:57:33PM -0500, Tom Lane wrote:
> So I started to work on back-patching the no-pallocs change in xml2.
> It seems to work fine in 8.4, but it crashes in 8.3.  The reason is
> that we never back-patched the 8.4 change to make utils/adt/xml.c
> not change the libxml2 memory allocation functions.  That means that
> if you try to intermix core xml operations with contrib/xml2
> operations, it fails because libxml2 is still trying to use the
> core's substituted memory alloc functions, and the contrib module
> isn't doing what's needful to make those actually work.
> This may explain the previous observations that 8.3's contrib/xml2
> didn't crash in as many cases as 8.4's does.  If core and contrib
> code both replace the allocation hooks, they're somewhat independent
> of each other.  When only one does, big trouble is what you've got.
> It seems like the most rational response to this is to go ahead and
> back-patch the 8.4 changes, specifically this patch
> into 8.3 so that we can also fix xml2.  I was afraid to do that back
> in May when the patch was committed, but by now we have enough field
> testing to suggest that 8.4 is no worse than 8.3 as far as the core
> xml operations go.
> Comments?

+1 for back-patching.

David Fetter <david(at)fetter(dot)org>
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://

Remember to vote!
Consider donating to Postgres:

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-03-01 01:02:51
Subject: contrib/xml2 vs core xml, more issues
Previous:From: Greg StarkDate: 2010-03-01 00:04:06
Subject: pgsql: add EPERM to the list of return codes to expect from opening

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group