You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A recent Sinter run of dbt archive encountered the dreaded:
SSL SYSCALL error: EOF detected
Relevant part of the call stack:
File "/usr/local/lib/python3.5/dist-packages/dbt/runner.py", line 89, in call_runner
result = runner.safe_run(manifest)
File "/usr/local/lib/python3.5/dist-packages/dbt/node_runners.py", line 121, in safe_run
self.adapter.release_connection(self.profile, node_name)
File "/usr/local/lib/python3.5/dist-packages/dbt/adapters/default/impl.py", line 494, in release_connection
cls.rollback(to_release)
File "/usr/local/lib/python3.5/dist-packages/dbt/adapters/default/impl.py", line 613, in rollback
connection.get('handle').rollback()
When it tries to rollback the transaction on that connection handle, postgres raises another exception which masks the original one and prints out connection already closed.
There was an earlier Failed to release connection! error -- I don't know if the two are related.
Difficult to repro since it depends on Postgres server failing in a specific way. However I imagine manually killing a postgres connection handle in the middle of an archive job would create similar behavior.
The text was updated successfully, but these errors were encountered:
Issue
Issue description
A recent Sinter run of
dbt archive
encountered the dreaded:Relevant part of the call stack:
When it tries to rollback the transaction on that connection handle, postgres raises another exception which masks the original one and prints out
connection already closed
.There was an earlier
Failed to release connection!
error -- I don't know if the two are related.System information
dbt version: 0.11.0
platform: Sinter
python version: 3.5
Steps to reproduce
Difficult to repro since it depends on Postgres server failing in a specific way. However I imagine manually killing a postgres connection handle in the middle of an archive job would create similar behavior.
The text was updated successfully, but these errors were encountered: