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

fix: the JDBC reWriteBatchedInserts=true option could cause errors in DML batches #713

Merged
merged 2 commits into from
Mar 9, 2023

Conversation

olavloite
Copy link
Collaborator

@olavloite olavloite commented Mar 8, 2023

The reWriteBatchedInserts=true JDBC option can cause the PG JDBC driver to execute a batch that contains different SQL statements, where one of the SQL statements in the middle of the batch must be described. The latter happens if the statement contains at least one untyped parameter. The JDBC driver sends all timestamp and date parameters as untyped, meaning that statements with parameters of those types could cause this problem. PGAdapter would then try to describe the statement as part of the batch, which is not possible, as ExecuteBatchDml does not support PLAN mode.

ExecuteBatchDml will normally throw a BatchUpdateException if something goes wrong in a batch. It is however possible that the entire batch fails, for example if the transaction has been aborted before the batch is sent and retrying the transaction fails because of concurrent modifications. Those errors would not be handled properly in PGAdapter and could cause PGAdapter to return the generic exception 'Statement result cannot be retrieved before flush/sync' instead of the actual underlying exception. This PR also adds error handling and tests for that possibility.

The reWriteInserts=true JDBC option can cause the PG JDBC driver to
execute a batch that contains different SQL statements, where one of the
SQL statements in the middle of the batch must be described. The latter
happens if the statement contains at least one untyped parameter. The
JDBC driver sends all timestamp and date parameters as untyped, meaning
that statements with parameters of those types could cause this problem.
PGAdapter would then try to describe the statement as part of the batch,
which is not possible, as ExecuteBatchDml does not support PLAN mode.
@codecov
Copy link

codecov bot commented Mar 8, 2023

Codecov Report

Merging #713 (3b39dd1) into postgresql-dialect (e0c6489) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@                  Coverage Diff                  @@
##             postgresql-dialect     #713   +/-   ##
=====================================================
  Coverage                 89.48%   89.49%           
- Complexity                 2347     2349    +2     
=====================================================
  Files                       129      129           
  Lines                      7712     7719    +7     
  Branches                   1103     1105    +2     
=====================================================
+ Hits                       6901     6908    +7     
  Misses                      563      563           
  Partials                    248      248           
Flag Coverage Δ
all_tests 89.49% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...panner/pgadapter/statements/BackendConnection.java 93.65% <100.00%> (+0.07%) ⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

ExecuteBatchDml will normally throw a BatchUpdateException if something
goes wrong in a batch. It is however possible that the entire batch
fails, for example if the transaction has been aborted before the batch
is sent and retrying the transaction fails because of concurrent
modifications. Those errors would not be handled properly in PGAdapter
and could cause PGAdapter to return the generic exception
'Statement result cannot be retrieved before flush/sync' instead of the
actual underlying exception. This commit adds error handling and tests
for that possibility.
@olavloite olavloite changed the title fix: do not execute analyze in a batch fix: the JDBC reWriteBatchedInserts=true option could cause errors in DML batches Mar 9, 2023
@olavloite olavloite merged commit 36bff88 into postgresql-dialect Mar 9, 2023
@olavloite olavloite deleted the analyze-in-batch branch March 9, 2023 08:53
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

Successfully merging this pull request may close these issues.

None yet

2 participants