Shay Rojansky wrote:
> Just to give some added reasoning...
>
> As Andres suggested, Npgsql sends ssl_renegotiation_limit=0 because we've seen renegotiation bugs with
> the standard .NET SSL implementation (which Npgsql uses). Seems like everyone has a difficult time
> with renegotiation.
As far as I remember, that was introduced because of renegotiation bugs with Mono:
http://lists.pgfoundry.org/pipermail/npgsql-devel/2010-February/001074.html
http://fxjr.blogspot.co.at/2010/03/ssl-renegotiation-patch.html
Of course, with renegotiation disabled, nobody knows whether there would also have been renegotiation
problems since Npgsql switched from Mono SSL to .NET SSL ...
> As Tom suggested, it gets sent in the startup packet so that DISCARD/RESET ALL resets back to 0 and
> not to the default 512MB (in older versions). Npgsql itself issues DISCARD ALL in its connection pool
> implementation to reset the connection to its original opened state, and of course users may want to
> do it themselves. Having SSL renegotiation accidentally turned on because a user sent RESET ALL, when
> the SSL implementation is known to have issues, is something to be avoided...
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.
If not, the only solution I can see is for PostgreSQL to not protest if it sees the
parameter in the startup packet.
Yours,
Laurenz Albe