-
Notifications
You must be signed in to change notification settings - Fork 21
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
feat: Add Copy command parsing in QueryMessage and basic psql e2e test #43
Conversation
src/main/java/com/google/cloud/spanner/pgadapter/wireprotocol/ControlMessage.java
Show resolved
Hide resolved
return new SyncMessage(connection); | ||
case TerminateMessage.IDENTIFIER: | ||
return new TerminateMessage(connection); | ||
case CopyDoneMessage.IDENTIFIER: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we allowed to receive CopyDone/CopyData/CopyFail if we're not in COPY_IN mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it should not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The build fails because of a compile error, I think because ConnectionStatus
is not imported by CopyDoneMessage
.
src/main/java/com/google/cloud/spanner/pgadapter/wireprotocol/CopyDoneMessage.java
Show resolved
Hide resolved
src/main/java/com/google/cloud/spanner/pgadapter/wireprotocol/CopyDoneMessage.java
Show resolved
Hide resolved
The e2e failures seem to be due to a change on the backend. There a new pg_catalog entries returned from the information schema. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once the test failures are fixed by #40
Copy messages should not respond with a Ready response, only with its own specific Copy responses. Failure to do so can cause the calling client to think that the operation has already finished, which again can cause the entire copy operation to fail if the connection is closed directly after receiving the Ready response. Also the current Copy operation should not execute a rollback if something fails, as it is operating in auto-commit mode. Trying to rollback when in auto-commit mode will cause an error.
@Vizerai I was wondering why the e2e-tests were failing, so I had a look at this PR and ended up doing a couple of small changes. It might be good if you go through those to check that you are OK with them before merging. |
The changes look good. Thanks for the update. |
instead of PG types.
No description provided.