[gdal-dev] OGR C API PostGIS geometry with wrong field entries

Even Rouault even.rouault at spatialys.com
Mon Dec 2 10:45:47 PST 2019


Markus,

> In the GRASS module v.in.ogr we follow pretty much the vector API tutorial.
> The only difference is that we first fetch the geometry of a feature, then
> the fields. When input is a PG database, sometimes the wrong field entries
> are associated with the geometries, as if geometries and field entries were
> mixed up. This happens when several different v.in.ogr processes are trying
> to read the same features from the same PG database at the same time. When
> instead using several different ogr2ogr processes, this mixing up of
> geometries and field entries does not happen. I could not find any hints in
> the OGR PostGIS documentation about how to avoid this problem.

This is indeed a weird problem. I don't have a theory. The PG driver 
implements a lot of lazy loading strategy to run efficiently with databases 
with many layers, but I wouldn't expect potential issues to be triggered by 
the fact that several v.in.org processes run in parallel... And I checked that 
fields returned from the PG system tables are sorted by attnum, so they should 
always be returned in the same order.

Are you sure there's no latent memory corruption in v.in.ogr ? Did you check 
with Valgrind ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list