[postgis-devel] PostGIS 1.4 RC1 vote

[Paragon Corporation]

Good point Paul.
Ah yes that was what exposed this particular long standing bug. Okay lets
fix it for 1.4 since its more of a serious issue for 1.4.  But we definitely
need to fix it for 1.3.7 as well.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Monday, June 29, 2009 4:11 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] PostGIS 1.4 RC1 vote

And 210 isn't longstanding, it's a result of my swapping the aggregates over
to using the side memory context instead of aggregating in the accum
function's memory context (and associated massive memcpy'ing).

P.

On Mon, Jun 29, 2009 at 1:07 PM, Mark
Cave-Ayland<mark.cave-ayland at siriusit.co.uk> wrote:
> Paragon Corporation wrote:
>
>> I really think the 212 can wait.  Its something that isn't even 
>> documented.
>> That can really wait till 1.4.1.  Remember we have a 1.4.1 and this 
>> would be a bug fix so can fit nicely in there.
>
> So you're saying that even though we now claim to support compound 
> curves within curved polygons, we should put a release that can't even 
> store and retrieve one of these geometries?! I'm not asking for us to 
> 100% proof check everything for 1.4.0, but as a bare minimum we must 
> be able to support storage and retrieval of the basic geometry.
>
>> I feel kind of the same about 210 (since I'm pretty sure we've had 
>> this problem for a really long time -- it might have been a change in 
>> PostgreSQL or something else that makes this more apparent thought).  
>> Though 210 is more of a serious issue since it does cause crashes 
>> under unpredicatable circumstances especially in 64-bit.
>
> Both of these of errors are caused by bad memory accesses (I know, 
> because I spent a lot of time fixing these in 1.3.6 as a result of the 
> torture test results). Just because the bad access doesn't manage to 
> crash on your particular platform/architecture on that particular 
> attempt, doesn't mean it will be harmless on another combination of 
> platform/architecture or won't fail at random points later within a longer
transaction.
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS 
> Sirius Corporation plc - control through freedom 
> http://www.siriusit.co.uk
> t: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel