-
Notifications
You must be signed in to change notification settings - Fork 820
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
Connection in poll broken once PGCopyInputStream fails #3163
Comments
So looking at your test by not reading the data from copy you are leaving data in the connection to be read using copy. Dave |
When pgCopy faily, I am closing the PgInputStream and closing the connection. Sorry for version mismatch, this problem also appears on 42.7.2 but Iw ill change here the version as in repo. The logs are actually showing that "CancelRequest" is being sent, but still next "select" gets data from previous reuest.
Before executing "SELECT * from example where id=1". we do have sendQueryCancel. Seems like COPY should be canceled, but after executing SELECT we get CopyData from backend |
Yes, this is what I understand to be happening as well. But I'm more interested in what is happening when copy fails as it appears it hasn't really failed. Dave |
Yes, currently the eviction is the only known solution for me. I might not understand you correctly, is it the intended behaviour? |
Well it's not the "intended behaviour" but it is the behaviour. I'm more curious what happens when copy fails. Do you have the stacktrace for that ? |
@PiotrDuz Do you have any more information to share ? |
@davecramer sorry for the delay. Have you tried maybe to run my reproduction example? I think it can easily help you get more picture |
@PiotrDuz I understand that, I want to know how the exception is being thrown in your production environment. |
Ah right. |
Well I think you need to fix your app logic. This behaviour is not something we can fix at the driver level. |
Describe the issue
We have noticed that when PGCopyInputStream fails during input stream reading, the connection even when being handled properly (within try block) will be broken for future calls to database when reused from the connection pool.
For example, if we fetch some data and copy fails during fetching, later select statement gets the residuals of previous COPY, even when the connection has been properly closed() (returned to the pool).
Please refer tot he example, as we are closing not only the connection but the PGCopyInputStream itself. The reproductible example is the simplest I could get, so error with unexpected data i not shown, rather the select just fails with no data.
Driver Version?
42.6.0
Java Version?
21
OS Version?
MacOS Sonoma 14.2.1 (23C71)
PostgreSQL Version?
DB version 14
To Reproduce
The repo contains the project that runs testcontainers and execute the tests:
https://github.com/PiotrDuz/pgcopy-exception-bug
We have the test when we dont throw an exception (error=false) and we don't evict connection (evict=false).
Second example, when we throw an exception (error=true) causes the connection (or socket ? ) to have some residual state from previous operation, so the next select fails.
Last example throws an error (error=true) but also evicts the connection (evict=true) thus we obtain fresh connection for select and it succeedes.
Please bear in mind that we use a HikariCP with maxConnection = 1, to always reuse a connection.
Expected behaviour
If pgCopy fails, it should clean all connection/socket states on close() so that connection can be reused.
Logs
I can extract any logs that are needed, but I strongly recommend to just quickly run reproductible example (or take alook at the code). Is the error handling done wrong?
Best regards
The text was updated successfully, but these errors were encountered: