Re: [HACKERS] Krb5 & multiple DB connections

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> The attached patch fixes a bug which was originally brought up in May
> of 2002 in this thread:

Now that I've looked at it, I find this patch seems fairly wrongheaded.
AFAICS the entire point of the original coding is to allow the setup
work needed to create the krb5_context etc to be amortized across
multiple connections. The patch destroys that advantage, but yet keeps
as much as it can of the notational cruft induced by the original
design -- for instance, there seems little point in the
pg_krb5_initialised flag if we aren't ever going to have any
pre-initialized state.

I have little idea of how expensive the operations called by
pg_krb5_init really are. If they are expensive then it'd probably
make sense to keep the current static variables but treat 'em as a
one-element cache, ie, recompute if a new user name is being demanded.
If not, we ought to be able to simplify some things.

Another point here is how all this interacts with thread safety.
If we get rid of the static variables, do we still need the
pglock_thread() operations?

regards, tom lane