[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