-
Notifications
You must be signed in to change notification settings - Fork 38
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
Exceptions thrown after upgrading to 3.4.0 & 3.4.4 #395
Comments
@pst9354 It would be great if we could create a reproduction test for this, otherwise this is not much to work with. Could you please give more context about the query and your setup? |
@isoos I don't think I can easily reproduce it. If I were to debug it, where should I start? |
As a start, a few information I would need: server version, what is the long-running query, what is the schema it is running on? It is very likely that this is related to a type serialization, either by a cast, or a plugin or a custom type. Any of this could be present here? |
I'm cloning their database to another machine at the moment. |
@pst9354 For many legal reasons I definitely won't do that. Please don't share any of your client data to anybody. |
I will of course anonymize the data, before sharing it. |
@pst9354 Please don't. I wouldn't risk any legal trouble by touching such data without written and signed agreements. We need to find other ways of debugging this. |
Ok, I will still need the clone to debug, so that I can reproduce it. |
Well, sadly I can't reproduce the error outside the live environment :-( |
I have reverted all our services to version 3.2.1. |
Please note that the difference between that and the new version is that the errors still happen, but you are not aware of them. |
Not in my case. In 3.2.1 the query will finnish and the Result is valid. In 3.4.4 the query will throw an exception and quit. I just had another run in a live environment, the try / catch doesn't catch it: |
The problem has been reported on two different servers, running:
After the reports, we reverted to 3.2.1 |
Any idea on what query was running? |
Example of query generating the error: SELECT * FROM (
) AS joined_order ORDER BY LPAD(customer_number, 32, '0'),LPAD(COALESCE(cc_number,''), 32, '0'),cc_number,pickup_time,shared_type DESC; |
sslMode: SslMode.disable Tried to reproduce the error in our production envirnoment, but I couldn't at the moment. |
Found a company/client instance that I could reproduce the error on. Run 1: SslMode.disable Run 2: SslMode.require Run 3: SslMode.disable Run 4: SslMode.require So yes, on my 4 test-runs, the SslMode.disable breaks things. |
An observation when enabling SslMode.require is that queries seems to run at half speed :-( |
Based on the error from the other issue and your report here, I'm fairly confident that #400 fixes the issue (the bug part anyway). As for the half speed, we should probably expand on that test in #400 and benchmark the library, I could imagine that there are trivial gains here and there. If you have a different benchmark than in the test, please submit it as a separate issue, I'll take a look into it possibly next week. Closing the issue as the newly published |
Thank you @isoos. |
I was finally able to reproduce the error and can confirm that 3.4.5 solves the problem. |
Edit: Had to revert to 3.2.1 to get it working.
Long running SQL query generates exception.
For 3.4.0:
Unhandled exception:
Bad state: Message parser consumed more bytes than expected. type=68 expectedLength=711
#0 MessageFramer.addBytes (package:postgres/src/message_window.dart:82:11)
#1 _readMessages...handleChunk (package:postgres/src/v3/protocol.dart:73:9)
For 3.4.4:
Unhandled exception:
Severity.error Socket error: Bad state: Not enough bytes to read.
#0 new _PgResultStreamSubscription (package:postgres/src/v3/connection.dart:758:29)
#1 _BoundStatement.listen (package:postgres/src/v3/connection.dart:728:12)
#2 _PreparedStatement.run (package:postgres/src/v3/connection.dart:677:43)
#3 _PgSessionBase.execute (package:postgres/src/v3/connection.dart:172:31)
#4 InvoiceJob.doInvoice (package:invoice_service/invoicejob.dart:2179:28)
#5 InvoiceQueue.handleInQueue. (package:invoice_service/invoice_queue.dart:423:17)
#6 InvoiceQueue.handleInQueue (package:invoice_service/invoice_queue.dart:419:7)
The text was updated successfully, but these errors were encountered: