Opened 10 years ago

Closed 5 years ago

#2771 closed defect (worksforme)

GDAL-dependent memory size of rasters ?

Reported by: strk Owned by: Bborie Park
Priority: medium Milestone:
Component: postgis Version: master
Keywords: Cc:

Description

Running "make check" locally works fine, but Travis fails on the ST_MemSize calls:

https://travis-ci.org/postgis/postgis/builds/28040817

Can it be size of rasters differ based on GDAL version ?

See #2770 for the ticket introducing ST_MemSize

Change History (10)

comment:1 by Bborie Park, 10 years ago

Yes. That is absolutely possible.

comment:2 by strk, 10 years ago

So tests should approximate, I guess…

comment:3 by strk, 10 years ago

It only happens on the outdb_template. Ah, it's a path issue I guess !!

comment:4 by strk, 10 years ago

different paths == different memory size

comment:5 by strk, 10 years ago

There are differences of 8 bytes and differences of 24 (8*3) bytes. Are paths embedded as absolute ?

comment:6 by Bborie Park, 10 years ago

Yes. Paths are always stored as absolute.

comment:7 by strk, 10 years ago

I'm trying to run the query so to subtract the length of band paths, but I stumbled upon what looks like being another bug: ST_BandPath returning random strings.

This query, put in raster/test/regress/rt_utiligy.sql right before my new test ("ms1"):

SELECT 'BandPath', rid, ST_BandPath(rast,1) from raster_outdb_template;         

Gives this output:

    band 1 of pixtype 8BUI is out-db with NODATA value of 255
     band 2 of pixtype 8BUI is in-db with NODATA value of 0
+BandPath|1|^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^S^B
+BandPath|2|^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?~^W^B
+BandPath|3|
+BandPath|4|^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?~^W^B
 ms1|64

Is there any test for ST_BandPath ? I guess this should go in another ticket…

comment:8 by strk, 10 years ago

Filed another ticket for the memory corruption (2.1.3 is also affected, possibly also 2.0.5): #2772

comment:9 by Bborie Park, 10 years ago

Fixed #2772 for all branches.

comment:10 by komzpa, 5 years ago

Resolution: worksforme
Status: newclosed

Travis does not fail on this anymore.

Note: See TracTickets for help on using tickets.