Re: [HACKERS] Krb5 & multiple DB connections

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Krb5 & multiple DB connections
Date: 2006-02-09 02:48:34
Message-ID: 22840.1139453314@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2006-02-09 02:52:44 Re: Upcoming re-releases
Previous Message Stephen Frost 2006-02-09 02:41:38 Re: Upcoming re-releases

Browse pgsql-patches by date

  From Date Subject
Next Message Stephen Frost 2006-02-09 03:03:34 Re: [HACKERS] Krb5 & multiple DB connections
Previous Message Tom Lane 2006-02-09 01:10:34 Re: BUG #2246: Bad malloc interactions: ecpg, openssl