Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1506 closed defect (fixed)

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

Reported by: joanw Owned by: Bborie Park
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 Bborie Park, 12 years ago

Component: postgispostgis raster
Owner: changed from pramsey to Bborie Park
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 Bborie Park, 12 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 Bborie Park, 12 years ago

Fixed in r8949.

comment:4 by Bborie Park, 12 years ago

Resolution: fixed
Status: assignedclosed

comment:5 by pracine, 12 years ago

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

comment:6 by Bborie Park, 12 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, 12 years ago

Any function modifying the data updates the flag.

comment:8 by Bborie Park, 12 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, 12 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.