Re: WITH HOLD and pooled connections

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
>
>

In response to

Browse pgsql-hackers by date

  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.