Re: Client/Server compression? - Mailing list pgsql-hackers

Greg Copeland <greg@CopelandConsulting.Net> writes:
> I'm talking about something that would be optional.  So, what's the cost
> of having a little extra optional code in place?

It costs just as much in maintenance effort even if hardly anyone uses
it.  Actually, probably it costs *more*, since seldom-used features
tend to break without being noticed until late beta or post-release,
when it's a lot more painful to fix 'em.

FWIW, I was not in favor of the SSL addition either, since (just as you
say) it does nothing that couldn't be done with an SSH tunnel.  If I had
sole control of this project I would rip out the SSL code, in preference
to fixing its many problems.  For your entertainment I will attach the
section of my private TODO list that deals with SSL problems, and you
may ask yourself whether you'd rather see that development time expended
on fixing a feature that really adds zero functionality, or on fixing
things that are part of Postgres' core functionality.  (Also note that
this list covers *only* problems in libpq's SSL support.  Multiply this
by jdbc, odbc, etc to get an idea of what we'd be buying into to support
our own encryption handling across-the-board.)

The short answer: we should be standing on the shoulders of the SSH
people, not reimplementing (probably badly) what they do well.
        regards, tom lane


SSL support problems
--------------------

Fix USE_SSL code in fe-connect: move to CONNECTION_MADE case, always
do initial connect() in nonblock mode.  Per my msg 10/26/01 21:43

Even better would be to be able to do the SSL negotiation in nonblock mode.
Seems like it should be possible from looking at openssl man pages:
SSL_connect is documented to work on a nonblock socket.  Need to pay attention
to SSL_WANT_READ vs WANT_WRITE return codes, however, to determine how to set
polling flag.

Error handling for SSL connections is a joke in general, not just lack
of attention to WANT READ/WRITE.

Nonblock socket operations are somewhat broken by SSL because of assumption
that library will only block waiting for read-ready.  Under SSL it could
theoretically block waiting for write-ready, though that should be a
relatively small problem normally.  Possibly add some API to distinguish which
case applies?  Not clear that it's needed, since worst possible penalty is a
busy-wait loop, and it doesn't seem probable that we could ever so block.
(Sure?  COPY IN could well block that way ... of course COPY IN hardly works
in nonblock mode anyway ...)

Fix docs that probably say SSL-enabled lib doesn't support nonblock.
Note extreme sloppiness of SSL docs in general, eg the PQREQUIRESSL env var
is not docd...

Ought to add API to set allow_ssl_try = FALSE to suppress initial SSL try in
an SSL-enabled lib.  (Perhaps requiressl = -1?  Probably a separate var is
better.)

Also fix connectDB so that params are accepted but ignored if no SSL support
--- or perhaps better, should requiressl=1 fail in that case?

Connection restart after protocol error is a tad ugly: closing/reopening sock
is bad for callers, cf note at end of PQconnectPoll, if the sock # should
happen to have changed.  Fortunately that's just a legacy-server case
(pre-7.0)