Re: [HACKERS] Krb5 & multiple DB connections
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Krb5 & multiple DB connections |
Дата | |
Msg-id | 22840.1139453314@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Krb5 & multiple DB connections (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [HACKERS] Krb5 & multiple DB connections
|
Список | 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 по дате отправления: