From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 |
Date: | 2004-07-05 21:35:22 |
Message-ID: | 4161.1089063322@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Gaetano Mendola | 2004-07-05 23:20:20 | Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 |
Previous Message | Alvaro Herrera | 2004-07-05 21:30:21 | Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2004-07-05 21:39:22 | Re: subtransactions and FETCH behaviour (was Re: PREPARE and transactions) |
Previous Message | Tom Lane | 2004-07-05 21:30:56 | Re: Recovery Features |