Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
russss opened this issue Oct 18, 2021 · 1 comment

Comments

@russss
Copy link
Contributor

russss commented Oct 18, 2021

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

  • Version used: 0.11.1
  • Postgres 13.2, PostGIS 3.1
@russss
Copy link
Contributor Author

russss commented Oct 18, 2021

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant