I am no Postgre expert but we have experienced similar cases when
running complex transactions with large geometries, i.e. faulty results.
When splitting the transaction into several pieces, i.e. enforcing
COMMITs (Postgre doesn't support COMMIT inside functions), the correct
results are given.
One guess is that this may happen for large geometries which are pushed
to TOAST tables.
Check Postgre memory parameters and trace exactly what is happening in
the database.
Test also with EXTERNAL STORAGE for the geometry if they are really large.
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.
Any hints are highly appreciated!
Markus M
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Hälsningar
Andreas Oxenstierna
T-Kartor Geospatial AB
Olof Mohlins väg 12 Kristianstad
mobile: +46 733 206831
mailto: a...@t-kartor.se
http://www.t-kartor.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
