From: | Shay Rojansky <roji(at)roji(dot)org> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL not setting OpenSSL session id context? |
Date: | 2017-08-04 18:48:20 |
Message-ID: | CADT4RqB2mx4BkJNjLbF3-vcMQiWCrrViJVnRcF4DGVEj0NOZDw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-08-04 18:49:29 | Re: pgsql 10: hash indexes testing |
Previous Message | Amit Kapila | 2017-08-04 18:45:48 | Re: pgsql 10: hash indexes testing |