-
Notifications
You must be signed in to change notification settings - Fork 877
Removed soft cancellation for the reader's sequential methods #3276
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
Changes from all commits
59e3467
5b04782
c9fb4a5
59f04b8
67d36f7
0df8ecc
771806d
32049d6
32484fc
2424d20
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -480,8 +480,8 @@ void DeriveParametersForQuery(NpgsqlConnector connector) | |
|
|
||
| foreach (var statement in _statements) | ||
| { | ||
| Expect<ParseCompleteMessage>(connector.ReadMessage(), connector); | ||
| var paramTypeOIDs = Expect<ParameterDescriptionMessage>(connector.ReadMessage(), connector).TypeOIDs; | ||
| Expect<ParseCompleteMessage>(connector.ReadMessageWithoutCancellation(), connector); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Any reason this shouldn't do PG cancellation?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This one is... actually, I'm not really sure about. Does it really can timeout because it was executing for too long?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Probably not - we're just asking the server to parse and describe the parameters. I think in my mind I wanted to default to trying cancellation, but like with COPY we can go with this and revisit later (this API specifically is in very low usage. |
||
| var paramTypeOIDs = Expect<ParameterDescriptionMessage>(connector.ReadMessageWithoutCancellation(), connector).TypeOIDs; | ||
|
|
||
| if (statement.InputParameters.Count != paramTypeOIDs.Count) | ||
| { | ||
|
|
@@ -515,7 +515,7 @@ void DeriveParametersForQuery(NpgsqlConnector connector) | |
| } | ||
| } | ||
|
|
||
| var msg = connector.ReadMessage(); | ||
| var msg = connector.ReadMessageWithoutCancellation(); | ||
| switch (msg.Code) | ||
| { | ||
| case BackendMessageCode.RowDescription: | ||
|
|
@@ -526,7 +526,7 @@ void DeriveParametersForQuery(NpgsqlConnector connector) | |
| } | ||
| } | ||
|
|
||
| Expect<ReadyForQueryMessage>(connector.ReadMessage(), connector); | ||
| Expect<ReadyForQueryMessage>(connector.ReadMessageWithoutCancellation(), connector); | ||
| sendTask.GetAwaiter().GetResult(); | ||
| } | ||
| } | ||
|
|
||
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.
Didn't we say we want PG cancellation when reading messages when exporting?
Thinking about this again, we can say that we don't think PG cancellation makes sense with COPY, because we don't think PG will hang for any reason (after all it's just pushing out data), so we only hang because of network issues. If this is true (it makes sense to me), we can just do hard cancellation. Interestingly we still allow sending PG cancellation via the Cancel method, but that wouldn't be because of hanging, just because the user decided mid-way to stop the long process.
I'm still not completely sure here.
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.
But we're not reading here a CopyDataMessage. Is there a reason you think, that reading a CopyOutResponseMessage may hang?
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.
Also, just like
RawCopyStream, here we're initializing the stream. Is it really OK to cancel, when we do not even know if the copy operation has really started?Uh oh!
There was an error while loading. Please reload this page.
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.
To be honest, I have no idea...
Let's go with your approach, and attempt cancellation only when reading CopyData. We can always adjust this later based on user feedback if we get any.