From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WITH HOLD and pooled connections |
Date: | 2003-08-09 01:58:06 |
Message-ID: | 3F34552E.60000@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Whew. To the best of my knowledge, JDBC at least doesn't provide any
API by which one could discover such a thing anyway, (although I guess a
given driver could implement some sort of statement cache with a name
lookup mechanism). I guess if it were part of the standards JDBC API
we'd have heard calls for its support by now. When you think about it
its a nice idea.
(You are right - all my prepped statements are used and disposed of
within a single use of a connection in a single thread.)
OK ... back to logging stuff ...
andrew
Tom Lane wrote:
>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>Prepared statements would be just as much of a problem. I think the
>>>correct answer is simply "don't use those features in a pooled
>>>environment".
>>>
>>>
>
>
>
>>Ouch. Double ouch in fact. I'm using prepared statements extensively in
>>my current (pooled conn) app. All pure selects.
>>Can this be narrowed down a bit? Is it a problem on all query types?
>>
>>
>
>The point is just that there's no infrastructure to manage prepared
>statements, eg for a thread to discover whether someone has already
>prepped a particular statement on the current connection. Evidently
>you have set things up so that you don't need to do that. Panic not.
>
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-08-09 02:12:09 | Re: WITH HOLD and pooled connections |
Previous Message | Bruce Momjian | 2003-08-09 01:07:27 | Re: UPDATED UnixWare Threads Patch. |