2016-06-08 8:26 GMT+02:00 Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp
> At Tue, 7 Jun 2016 12:18:31 +0200, Magnus Hagander <mag...@hagander.net>
> wrote in <
> > On Tue, Jun 7, 2016 at 11:31 AM, Pavel Stehule <pavel.steh...@gmail.com>
> > wrote:
> > >> That's definitely not expected behavior. hostnossl should turn off ssl
> > >> which should turn off the overhead completely. Does it make a
> difference if
> > >> you also disable it from the client side?
> > >>
> > >
> > > When I explicitly disabled ssl, then I seen significantly less time
> > >
> > >
> > Intersting. Can you check with a network trace that it actually turns off
> > ssl, so nothing is broken there?
> > One thing that could be taking the time is an extra roundtrip -- e.g. it
> > tries to connect with ssl fails and retries without. A network trace
> > also make this obvious, and can hopefully show you exactly where in the
> > connection the time is spent.
> As Tom said, setting sslmode=allow or disable prevents
> reconnection against hostnossl.
> > psql "sslmode=disable host=127.0.0.1 dbname=postgres"
> There are 4 (disable, allow, prefer, require) * 3 (host, hostssl,
> hostnossl) = 12 possible combinations (ignoring veryfy-* of
> sslmode) of SSL usage preferences. Among these, the following two
> combinations needs reconnection.
> prefer + hostnossl , allow + hostssl
> Since no client can find whether a user can connect using (or not
> using) SSL before making any connection, reconnection is
> inevitable for the above combinations.
> By the way, SSL initialization takes place only when server is
> requested SSL connection (NEGOTIATE_SSL_MODE), so only prefer +
> hostnossl causes the wasting SSL intialization.
Thank you for detailed info
> Kyotaro Horiguchi
> NTT Open Source Software Center