Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2
Дата
Msg-id
4161.1089063322@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 Bruce Momjian <pgman@candle.pha.pa.us>
Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 Gaetano Mendola <mendola@bigfoot.com>
Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 Tom Lane <tgl@sss.pgh.pa.us>
Alvaro Herrera  writes:
> I wonder why is this?  Is there some limitation to using palloc outside
> the backend itself?  I ask because I have considered using it outside
> Postgres several times (a consideration that has never materialized
> yet), and I wonder if it needs something special to work.

It's useless without the rest of the backend infrastructure, including
elog error recovery and a cooperative main loop.  You could certainly
reuse the code in a different application if you were willing to adopt
Postgres' memory management and error handling approaches
lock-stock-and-barrel, but I don't think you could be selective about
it.  For a library that has to work inside a not-so-cooperative
application, the idea is a nonstarter.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Alvaro Herrera
Дата:
От: Tom Lane
Дата:
Сообщение: Re: Point in Time Recovery
FAQ