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
> launched.
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
PostgreSQL instances.
Andreas