On 2017-06-06 22:53, dieter wrote:
israel <isr...@ravnalaska.net> 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 False), or should it
close them as long as there is more than minconn open? i.e is my
observed behavior a bug or a feature?
You should ask the author[s] of "psycopg2" about the supposed behavior.
From my point of view, everything depends on the meaning of the "min"
and "max" parameters for the pool.
You seem to interprete "max" as "keep as many connections as this
open".
But it can also be a hard limit in the form "never open more than this
number of connections". In the latter case, "min" may mean "keep this
many connections open at all time".
You are right about my interpretation of "max", and also about the
actual meaning. Thus the reason I was asking :-). I did post on the bug
report forum, and was informed that the observed behavior was the
correct behavior. 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).
So let me ask a different, but related, question: Is there a Python
library available that gives me the behavior I described in my first
post, where connections are "cached" for future use for a time? Or
should I just write my own? I didn't find anything with some quick
googling, other than middleware servers like pgpool which, while they
have the behavior I want (at least from my reading), will still require
the overhead of making a connection (perhaps less than direct to
postgres? Any performance comparisons out there?), not to mention
keeping yet another service configured/running. I would prefer to keep
the pool internal to my application, if possible, and simply reuse
existing connections rather than making new ones. Thanks!
--
https://mail.python.org/mailman/listinfo/python-list
