Re: [HACKERS] Krb5 & multiple DB connections - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] Krb5 & multiple DB connections
Date
Msg-id 22840.1139453314@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Krb5 & multiple DB connections  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] Krb5 & multiple DB connections  (Stephen Frost <sfrost@snowman.net>)
List pgsql-patches
Stephen Frost <sfrost@snowman.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

pgsql-patches by date:

Previous
From: Simon Riggs
Date:
Subject: Re: External Sort performance patch
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Krb5 & multiple DB connections