At Tue, 7 Jun 2016 12:18:31 +0200, Magnus Hagander <mag...@hagander.net> wrote in <cabuevez5qrmq4ebysbz+ujfg_3_ap361zqtgbh_ef+2j6p0...@mail.gmail.com> > 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 should > 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. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
