Opened 5 years ago

Closed 4 months 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 Changed 5 years ago by Bborie Park

Yes. That is absolutely possible.

comment:2 Changed 5 years ago by strk

So tests should approximate, I guess...

comment:3 Changed 5 years ago by strk

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

comment:4 Changed 5 years ago by strk

different paths == different memory size

comment:5 Changed 5 years ago by strk

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

comment:6 Changed 5 years ago by Bborie Park

Yes. Paths are always stored as absolute.

comment:7 Changed 5 years ago by 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...

comment:8 Changed 5 years ago by strk

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

comment:9 Changed 5 years ago by Bborie Park

Fixed #2772 for all branches.

comment:10 Changed 4 months ago by komzpa

Resolution: worksforme
Status: newclosed

Travis does not fail on this anymore.

Note: See TracTickets for help on using tickets.