Re: WITH HOLD and pooled connections - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: WITH HOLD and pooled connections
Date
Msg-id 3F34552E.60000@dunslane.net
Whole thread Raw
In response to Re: WITH HOLD and pooled connections  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@dunslane.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
>  
>



pgsql-hackers by date:

Previous
From: Manfred Koizar
Date:
Subject: Re: Correlation in cost_index()
Next
From: Neil Conway
Date:
Subject: Re: WITH HOLD and pooled connections