GDAL-dependent memory size of rasters ?

[strk]

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

[dustymugs]

Yes. That is absolutely possible.

[strk]

So tests should approximate, I guess…

[strk]

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

[strk]

different paths == different memory size

[strk]

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

[dustymugs]

Yes. Paths are always stored as absolute.

[strk]

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…

[strk]

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

[dustymugs]

Fixed #2772 for all branches.

[komzpa]

Travis does not fail on this anymore.