Simple fix for contrib/xml2

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Simple fix for contrib/xml2
Дата
Msg-id 12315.1267385157@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Simple fix for contrib/xml2  (Bruce Momjian <bruce@momjian.us>)
Re: Simple fix for contrib/xml2  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after