On 08/04/2017 08:48 PM, Shay Rojansky wrote:
On 2017-08-04 07:22:42 +0300, Shay Rojansky wrote:
> I'm still not convinced of the risk/problem of simply setting the session
> id context as I explained above (rather than disabling the optimization),
> but of course either solution resolves my problem.
How would that do anything? Each backend has it's own local
memory. I.e. any cache state that openssl would maintain wouldn't be
useful. If you want to take advantage of features around this you really
need to cache tickets in shared memory...
Guys, there's no data being cached at the backend - RFC5077 is about
packaging information into a client-side opaque session ticket that
allows skipping a roundtrip on the next connection. As I said, simply
setting the session id context (*not* the session id or anything else)
makes this feature work, even though a completely new backend process is
Yes, session tickets are encrypted data which is stored by the client.
But if we are going to support them I think we should do it properly
with new GUCs for the key file and disabling the feature. Using a key
file is less necessary for PostgreSQL than for a web server since it is
less common to do round robin load balancing between different
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: