try to read any notifies or errors that come in asynchronously #2143
Conversation
…an I/O exception to a PSQLException
…an I/O exception to a PSQLException fix failing copy test. show type of exception fix failing copy test. check instance of cause fix failing copy test. just use SQLException fix style
…est for fatal termination
|
interestingly this test does not fail locally. |
That's because |
|
You do realize the kill is being sent on a different connection, right ? |
|
Right now the test works like this:
AFAIK PG doesn't notify other connections if one of them is dead, so I assume pgjdbc just closes other open connections if there is a problem with a host. Which leads me to believe that although there is no race condition between killing the backend and sending another query, there is a race condition between killing the backend and reading a response from the second step. Essentially, the second step might not throw an exception. Correct me if I've missed something. |
|
Yes, PG does notifiy other connections if the connection is killed in such a way that causes a restart of the backend. Before it restarts it will send out the warning to all active connections and then restart. That is the whole point of this PR and the test. As I said this works fine locally. |
I actually didn't know that, thank you! Was able to reproduce this behavior on linux and partially on windows (I was unable to read a notice, but it's most likely due to windows socket implementation). Still, just to test the theory of a |
|
This test seems to be a little too destructive. On travis the db does not recover very quickly |
Merge done to get the perf issue addressed in upstream which was introduced in the upstream earlier. The upstream pgjdbc ( on 42.3.0 ) had introduced this performance issue in rb3d5fba91a9ddbd6c7e6bfce774f0c0cc94593b9 This issue was reverted later on Oct 7th this year in commit: c4c35d1 Commit comment: Revert "try to read any notifies or errors that come in asynchronously" (pgjdbc#2276) Revert "fix: try to read any notifies or errors that come in asynchronously (try to read any notifies or errors that come in asynchronously pgjdbc#2143)" This reverts commit b3d5fba. fix spacing on GSS_ENC_MODE (fix spacing on GSS_ENC_MODE [SKIP-CI] pgjdbc#2280)
…-yugabytedb driver Summary: The degradation was because the upstream pgjdbc ( on 42.3.0 ) had introduced this performance issue in rb3d5fba91a9ddbd6c7e6bfce774f0c0cc94593b9 … upstream repo: git@github.com:pgjdbc/pgjdbc.git This issue was reverted later on Oct 7th this year in commit: c4c35d1 ``` Commit comment: Revert "try to read any notifies or errors that come in asynchronously" (pgjdbc#2276) Revert "fix: try to read any notifies or errors that come in asynchronously (try to read any notifies or errors that come in asynchronously pgjdbc/pgjdbc#2143)" This reverts commit b3d5fba. fix spacing on GSS_ENC_MODE (fix spacing on GSS_ENC_MODE [SKIP-CI] pgjdbc/pgjdbc#2280) ``` But by that time we had already forked our repo. With this change there was some unnecessary read of the sockets happening and in the process some buffer allocation happening which was the cause of the slowness. I have merged the latest version i.e. 42.3.2 in our fork. The smart driver jar referenced in the yb-pgsql pom.xml is the latest fixed version now. Test Plan: yb-sample-apps yb-pgsql unit tests smart driver demo apps in: https://github.com/yugabyte/pgjdbc/tree/master/examples Reviewers: nikhil, ashetkar, mihnea, ssong Reviewed By: ssong Subscribers: ssong, yql Differential Revision: https://phabricator.dev.yugabyte.com/D14504
…est jdbc-yugabytedb driver Summary: The degradation was because the upstream pgjdbc ( on 42.3.0 ) had introduced this performance issue in rb3d5fba91a9ddbd6c7e6bfce774f0c0cc94593b9 … upstream repo: git@github.com:pgjdbc/pgjdbc.git This issue was reverted later on Oct 7th this year in commit: c4c35d1 ``` Commit comment: Revert "try to read any notifies or errors that come in asynchronously" (pgjdbc#2276) Revert "fix: try to read any notifies or errors that come in asynchronously (try to read any notifies or errors that come in asynchronously pgjdbc/pgjdbc#2143)" This reverts commit b3d5fba. fix spacing on GSS_ENC_MODE (fix spacing on GSS_ENC_MODE [SKIP-CI] pgjdbc/pgjdbc#2280) ``` But by that time we had already forked our repo. With this change there was some unnecessary read of the sockets happening and in the process some buffer allocation happening which was the cause of the slowness. I have merged the latest version i.e. 42.3.2 in our fork. The smart driver jar referenced in the yb-pgsql pom.xml is the latest fixed version now. Test Plan: yb-sample-apps yb-pgsql unit tests smart driver demo apps in: https://github.com/yugabyte/pgjdbc/tree/master/examples Reviewers: nikhil, ashetkar, mihnea, ssong Reviewed By: ssong Subscribers: ssong, yql Differential Revision: https://phabricator.dev.yugabyte.com/D14504
Lets see what this breaks