Shay Rojansky

@happybald can you confirm 6.0 performs well, and that we can close the issue?

We discussed this offline, here are some intermediary options and thoughts: 1. We can specifically address the single-row case for ExecuteReader by buffering a row ahead (as suggested above by...

@tamas-nucleus I tend to agree that throwing from Dispose seems like the least bad option here, and has the advantage of at least being discoverable (as opposed to swallowing exceptions)......

Decision: we'll start throwing exceptions from Dispose, as the least bad option here. As "inspiration", FileStream also throws from Dispose.

We did a bunch of work for 6.0 in #3300 - I think most of the base functionality should be compatible. I know there's certain functionality that doesn't work, and...

#4222 this was at least originally by design - when batching isn't used, it didn't seem to make sense to populate PostgresException.BatchCommand. This also wouldn't provide any information that the...

@kaiohenrique which version of Npgsql are you using? Assuming it's a modern version (i.e. 6.0), the only use of event pipe should be via the [event counters](https://www.npgsql.org/doc/diagnostics/metrics.html) which Npgsql emits...

@stmax82 this seems more like a PostgreSQL question than an Npgsql one. I'd also expect this exception during open and not command execution - unless you're using a connection pool...

>> unless you're using a connection pool such as pg_bouncer > > No, we aren't using pg_bouncer. This is a Postgres "Single Server" database in Azure. I think it doesn't...

I'm just a bit frustrated that we had a design discussion about how to go about this, and it didn't occur to me to make these comments back then. >...