Ticket #1506 (closed defect: fixed)

Opened 17 months ago

Last modified 17 months ago

[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

Changed 17 months ago by dustymugs

  • owner changed from pramsey to dustymugs
  • priority changed from medium to blocker
  • status changed from new to assigned
  • component changed from postgis to postgis raster
  • summary changed from ST_Quantile('rastertable' ...) segfault and is missing in documentation to [raster] ST_Quantile('rastertable' ...) segfault and is missing in documentation

Changed 17 months ago by dustymugs

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).

Changed 17 months ago by dustymugs

Fixed in r8949.

Changed 17 months ago by dustymugs

  • status changed from assigned to closed
  • resolution set to fixed

Changed 17 months ago by pracine

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

Changed 17 months ago by dustymugs

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.

Changed 17 months ago by pracine

Any function modifying the data updates the flag.

Changed 17 months ago by dustymugs

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.

Changed 17 months ago by pracine

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.