omniscale / imposm3

Imposm imports OpenStreetMap data into PostGIS
http://imposm.org/docs/imposm3/latest/
Apache License 2.0
710 stars 156 forks source link

Undesired behaviour when SQL error is experienced updating generalized tables #279

Open russss opened 2 years ago

russss commented 2 years ago

If there's an SQL error during update of generalized tables, imposm run continues with the generalized table update to the end, despite the Postgres transaction being aborted, and the only error reported by imposm is:

 [error] Importing #4758661: pq: Could not complete operation in a failed transaction

This error isn't helpful, and because imposm does not detect the transaction is aborted, there are many current transaction is aborted, commands ignored until end of transaction block errors in the Postgres logs, which make it tedious to dig out the original error.

If there is an error, imposm should immediately abort the update and report the original error to the imposm logs. It should not keep feeding statements into an aborted transaction which fill up the Postgres logs with errors.

Your Environment

russss commented 2 years ago

It looks like this only happens for runtime (rather than prepare-time) SQL errors. Calling an undefined function results in the expected behaviour of the error being reported.

The undesired behaviour is happening when the function emits a runtime error (ERROR: invalid input syntax for type numeric).