On 2017-06-08 19:55, Ian Kelly wrote:
On Thu, Jun 8, 2017 at 10:47 AM, Israel Brewster
wrote:
On Jun 7, 2017, at 10:31 PM, dieter wrote:
israel writes:
On 2017-06-06 22:53, dieter wrote:
...
As such, using psycopg2's pool
On Thu, Jun 8, 2017 at 10:47 AM, Israel Brewster wrote:
>> On Jun 7, 2017, at 10:31 PM, dieter wrote:
>>
>> israel writes:
>>> On 2017-06-06 22:53, dieter wrote:
>>> ...
>>> As such, using psycopg2's pool is essentially
>>>
---
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
---
> On Jun 7, 2017, at 10:31 PM, dieter wrote:
>
> israel
israel writes:
> On 2017-06-06 22:53, dieter wrote:
> ...
> As such, using psycopg2's pool is essentially
> worthless for me (plenty of use for it, i'm sure, just not for me/my
> use case).
Could you not simply adjust the value for the "min" parameter?
If you want at least
On 2017-06-06 22:53, dieter wrote:
israel writes:
Since I've gotten no replies to this, I was wondering if someone could
at least confirm which behavior (my expected or my observed) is
*supposed* to be the correct? Should a psycopg2 pool keep connections
open when
israel writes:
> Since I've gotten no replies to this, I was wondering if someone could
> at least confirm which behavior (my expected or my observed) is
> *supposed* to be the correct? Should a psycopg2 pool keep connections
> open when returned to the pool (if closed is
Since I've gotten no replies to this, I was wondering if someone could
at least confirm which behavior (my expected or my observed) is
*supposed* to be the correct? Should a psycopg2 pool keep connections
open when returned to the pool (if closed is False), or should it close
them as long as
I've been using the psycopg2 pool class for a while now, using code similar to
the following:
>>> pool=ThreadedConnectionPool(0,5,)
>>> conn1=pool.getconn()
>>>
>>> pool.putconn(conn1)
repeat later, or perhaps "simultaneously" in a different thread.
and my understanding was that the pool