Of course, with renegotiation disabled, nobody knows whether there would also have been renegotiation problems since Npgsql switched from Mono SSL to .NET SSL ...
You may be right (this was before my time on Npgsql). But since PostgreSQL is dropping negotiation on its side it doesn't really make sense to dive into this and find out if it's still buggy or not...
Maybe Npgsql could switch to sending the statement after the connection has been established and resending it after each RESET ALL? You could add documentation that people should not use RESET ALL with Npgsql unless they are ready to disable renegotiation afterwards.
That's certainly possible, although it seems problematic to prohibit RESET ALL because of an issue like this. It's a useful feature that users may want to use as they manipulate parameters, that's why PostgreSQL has it in the first place...
I also prefer not to rely on documentation warnings which people may miss, especially in this case where the consequences of accidentally turning on renegotiation with a buggy stack would be extremely difficult to track and debug...
If not, the only solution I can see is for PostgreSQL to not protest if it sees the parameter in the startup packet.
Yeah, that's the ideal solution here as far as I'm concerned.
