On 2014-08-28 10:20:08 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-08-28 10:12:19 -0400, Tom Lane wrote:
> >> Hm. Yeah, I guess there is some use in holding onto the values that were
> >> actually used to initialize the current session, or at least there would
> >> be if we exposed the cert contents in any fashion.
>
> > Won't that allow the option to be specified at connection start by mere
> > mortal users? That sounds odd to me.
>
> Well, no, because SSL would be established (or not) before we ever process
> the contents of the connection request packet. You might be able to
> change the value that SHOW reports, but not the value actually governing
> your session.
Sure. There's probably nothing happening with ssl 'that late' right
now. But and it seems like a invitation for trouble later to me. Even if
it's just that other code copies the logic, thinking it'd also be safe.
> Having said that, there's a nearby thread about inventing a "SUBACKEND"
> GUC category, and that's likely what we'd really want to use here, just
> on the grounds that superusers would know better.
What we really want is PGC_SIGHUP | PGC_BACKEND, right? I wonder if it's
not better to allow for some cominations of GucContext's by bitmask,
instead of adding SUBACKEND and HUPBACKEND and whatever else might make
sense.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
