[postgis-devel] Bogus PROJ4 memory context definition crashes Postgres
mark.cave-ayland at ilande.co.uk
Thu Jul 12 13:37:00 PDT 2007
On Wed, 2007-07-11 at 16:14 -0400, Tom Lane wrote:
> Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk> writes:
> > On Wed, 2007-07-11 at 15:03 -0400, Tom Lane wrote:
> >> If an "out of memory" condition occurs while using transform(),
> >> Postgres will crash every time, because the memory manager code
> >> will try to dump memory context stats to the postmaster log ...
> >> and the Postgis code doesn't provide a stats method for its custom
> >> memory context type. Providing this method type is not optional.
> > Oops. That code is my fault - I'll see if I can come up with a patch to
> > fix this. Is this easy to simulate just with a large palloc()?
> All you need is a stats-printing routine. The minimum version would
> look something like
> static void
> PROJ4SRSCacheStats(MemoryContext context)
> "%s: PROJ4 context\n",
> though perhaps there are useful bits of info you could add to the
> printout --- maybe the srid would be worth including for instance.
> >> I do not think the reset and is_empty methods are optional either,
> >> although I don't have such a simple example of where they might
> >> get called.
> > Will look at these too. The only reason the MemoryContext exists in the
> > first place is because we need to be able to cache library handles for
> > PROJ.4, and so we need a hook when the backend exits in order to free
> > all the handles we have used. Do you know of a better way of doing this,
> > preferably with compatibility down to PostgreSQL 7.2?
> Actually I thought it was a pretty cute solution. You just need to
> support all the methods that anyone might call. I don't think they
> need to do much --- it's probably all right if reset() does nothing,
> and is_empty() can just always return false.
> regards, tom lane
Should now be fixed in the latest SVN:
give the latest version.
ILande - Open Source Consultancy
More information about the postgis-devel