| From: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
|---|---|
| To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Michael Meskes <meskes(at)postgresql(dot)org>, Austin Gonyou <austin(at)coremetrics(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Commercial binary support? |
| Date: | 2003-11-23 14:04:35 |
| Message-ID: | Pine.LNX.4.21.0311231354180.13011-100000@ponder.fairway2k.co.uk |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 23 Nov 2003, Oleg Bartunov wrote:
> does tsearch2 in 7.4 still has the problem ? I apologies if we miss your
> patches but certainly we're interested in clear explanation of the problem.
The problem was memory allocations made through malloc and family were not
being checked for failure before attempts made to use the memory, i.e. null
pointer dereference.
Tom or Bruce applied the patch in time for 7.4 release.
The only issue with this was noone knew how the version of tsearch2 for
PostgeSQL 7.3 was being maintained. I think I posted the patch for that to at
least one of the lists but as I am using tsearch2 on 7.3 I also threw this into
my own CVS.
In short, I don't think there's anything to worry about in relation to my
patches and 7.4.
Just to remind you though, the original fault reporter reported he was still
getting the fault after applying what I assume was my patches. Which surprised
me as I expected the fault location to be moved somewhere else. I think the
real problem he was having was that of memory exhaustion but we never got more
than basic information for this last report.
Nigel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dennis Bjorklund | 2003-11-23 16:53:11 | Function parameter names |
| Previous Message | Andreas Pflug | 2003-11-23 12:39:24 | Re: pg_dump dependency / physical hot backup |