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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
