This needs to be done for sequential mode only (CommandBehavior.SequentialAccess), since in normal mode entire rows are always buffered in memory.
Also, this is about cancellation/timeout while we are in the middle of a DataRow message. Unless I'm missing something, I don't think it is not possible or meaningful to do PostgreSQL cancellation - the DataRow message must be fully read to its end, otherwise we lose protocol sync. I think this means we can only do hard socket cancellation here. I also suspect that there is no case where PG will block while sending data in the middle of a row, and PG cancellation would unblock it - this is most probably only about network issues anyway (so again, only socket cancellation should be relevant).
Since this is a bit of an edge case and affects only sequential mode, it may be OK to push this out of 5.0.0 (but note that ExecuteScalar does sequential mode as an optimization).
/cc @vonzshik
This needs to be done for sequential mode only (CommandBehavior.SequentialAccess), since in normal mode entire rows are always buffered in memory.
Also, this is about cancellation/timeout while we are in the middle of a DataRow message. Unless I'm missing something, I don't think it is not possible or meaningful to do PostgreSQL cancellation - the DataRow message must be fully read to its end, otherwise we lose protocol sync. I think this means we can only do hard socket cancellation here. I also suspect that there is no case where PG will block while sending data in the middle of a row, and PG cancellation would unblock it - this is most probably only about network issues anyway (so again, only socket cancellation should be relevant).
Since this is a bit of an edge case and affects only sequential mode, it may be OK to push this out of 5.0.0 (but note that ExecuteScalar does sequential mode as an optimization).
/cc @vonzshik