Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1506 closed defect (fixed)

[raster] ST_Quantile('rastertable' ...) segfault and is missing in documentation

Reported by: joanw Owned by: dustymugs
Priority: blocker Milestone: PostGIS 2.0.0
Component: raster Version: 2.0.x
Keywords: Cc:

Description

ST_Quantile for raster table has segfault. There is no documentation for the same.

Change History (9)

comment:1 by dustymugs, 13 years ago

Component: postgispostgis raster
Owner: changed from pramsey to dustymugs
Priority: mediumblocker
Status: newassigned
Summary: ST_Quantile('rastertable' ...) segfault and is missing in documentation[raster] ST_Quantile('rastertable' ...) segfault and is missing in documentation

comment:2 by dustymugs, 13 years ago

The segfault happens when the quantile's linked list has no elements but is being used to get the quantile value. This happens when the linked list is newly initialized AND the raster band has no valid values (everything is NODATA).

comment:3 by dustymugs, 13 years ago

Fixed in r8949.

comment:4 by dustymugs, 13 years ago

Resolution: fixed
Status: assignedclosed

comment:5 by pracine, 13 years ago

This is why we planned a ISNODATA flag: to optimize some process when every pixel are NODATA. See #593.

comment:6 by dustymugs, 13 years ago

I don't see an easy way to keep ISNODATA flag in sync with changes to the data. Probably something to discuss for 2.1.

comment:7 by pracine, 13 years ago

Any function modifying the data updates the flag.

comment:8 by dustymugs, 13 years ago

The problem is that if you are manipulating many pixels at once, you have to inspect every value for NODATA, which could dramatically slow down a function.

comment:9 by pracine, 13 years ago

In this case you set the flag to false even if what you are setting is only nodata and you loose the optimization. You can ST_Rescan() all the rasters to reset the flag once a week if you do a lot of edit (like a SQL VACUUM). This is ONLY if you edit the rasters, which is a fraction of the applications. Other application always get the optimization. This is what I discussed with Jorge.

A lot of code and changes for not much optimization for coverages having at least one tile complete with nodata which are not all of them… Really a low priority.

I'm glad that this argument discard the idea of having empty tiles when only filled with nodata. You would also have to check for every edited pixel in order to determine if the resulting tile is all nodata to make it empty…

Note: See TracTickets for help on using tickets.