Nikita Kazmin

@happybald just to check, if you rewrite the query like this: ```sql SELECT output FROM calccache WHERE hash = (@hash)::bpchar ``` Does it help?

OK, to explain what's going on. Since around 3.0 Npgsql started using an extended query protocol (which allows us to send parameters as a separate entities), instead of a simple...

`psql` reports an error immediately because it does read everything PG sends before returning a result set, unlike `ExecuteReader`, which reads row by row. On the contrary, `ExecuteNonQuery` and `ExecuteScalar`...

Okay, I was wrong: even calling `Read` you wouldn't get an exception - you can only get it by calling `NextResult`. I would have advised to use `ExecuteScalar`, but it...

I do agree it's dangerous, but I don't see any way to implement throwing that error on the first `Read`. Right now PG sends us 3 messages: ``` Data Row...

> Having said that, there's probably no harm in always populating the property... Sure, why not.

Hello. I have a few questions for you: 1. With repmgr, am I correct to assume that you switch cluster roles by executing `repmgr standby switchover`? 2. Could you add...

OK, one more thing. If you add `Npgsql.Internal.ClusterStateCache.Clear()` just before you open the connection, does it help?

OK, so it looks like the cluster's state in cache for some reason doesn't expire. I'll try to reproduce the issue.

I was able to repro the problem. What's happening is: 1. The app connects to the first host and starts sending queries to it (it's primary and that's exactly what...