Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

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