On 4/6/06, Seth Falcon <[EMAIL PROTECTED]> wrote:
> So it looks like the Python Dispatcher project has some updates
> related to this. On their website_ they have:
>
> # Version 1.0.3
>
> * Patch bug in SafeRef deletion where traceback module has already
> been deleted by interpreter
"Istvan Albert" <[EMAIL PROTECTED]> writes:
>> I don't understand how the traceback module ends up being None
>
>> Adding a check for None will make the warning message go away
>
> fixing up code to make a mysterious error message go away is vey very
> suboptimal (ok ... so I've done I it myself a
Adrian Holovaty wrote:
>Django has closed the database connection on every request for as long
>as I remember. The very first open-source version had it --
>http://code.djangoproject.com/browser/django/tags/notable_moments/ipo/django/core/handler.py#L32
>-- and we had that db.db.close() for every
On Apr 5, 2006, at 8:29 PM, Adrian Holovaty wrote:
> Django has closed the database connection on every request for as long
> as I remember. The very first open-source version had it --
> http://code.djangoproject.com/browser/django/tags/notable_moments/
> ipo/django/core/handler.py#L32
> -- and
> I don't understand how the traceback module ends up being None
> Adding a check for None will make the warning message go away
fixing up code to make a mysterious error message go away is vey very
suboptimal (ok ... so I've done I it myself a few times as well ...)
--~--~-~--~~--
On 4/5/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Again, I really want to back this change out. My off-the-cuff
> measurements (not very good, probably) show about a 5% performance
> hit when closing the connection each time, and although that's not
> much, that's 5% less hardware I have
On Wednesday 05 April 2006 23:07, gabor wrote:
> hi Jacob, many thanks for the explanation.
>
> (and sorry to jump into the discussion)..
>
> the original poster (luke plant) said that:
>
> "
> It appears
> that connections are not being closed at all. With every hit I'm
> getting another entry
Jacob Kaplan-Moss wrote:
>
> On Apr 5, 2006, at 2:09 PM, Ivan Sagalaev wrote:
>> How can this work? Django app connects to Postgres through psycopg,
>> how
>> Apache can "hold" the connections that it doesn't know anything about?
>> Or does it?
>
> It's not "holding" connections, per se... let
On Apr 5, 2006, at 4:01 PM, Rudolph wrote:
> I'm not an expert on this subject but if I understand it correctly the
> database should accept at least as many connections as Apache can
> handle client connections (and if that's too much, you can use
> pg_pool)? Allowing a bit more connections would
I'm not an expert on this subject but if I understand it correctly the
database should accept at least as many connections as Apache can
handle client connections (and if that's too much, you can use
pg_pool)? Allowing a bit more connections would be nice otherwise you
can't at the same time conne
On Apr 5, 2006, at 2:09 PM, Ivan Sagalaev wrote:
> How can this work? Django app connects to Postgres through psycopg,
> how
> Apache can "hold" the connections that it doesn't know anything about?
> Or does it?
It's not "holding" connections, per se... let me see if I can explain
it more cl
Jacob Kaplan-Moss wrote:
>It's not pooling per se; it's persistent connections. What happens
>is that when the request ends the Apache process isn't gc'd so the
>connection stays open. When the next request comes in to the same
>child, the connection is reused.
>
>
How can this work? Dj
On Apr 5, 2006, at 1:18 PM, Ivan Sagalaev wrote:
> The problem is that Django does not reuse these open connections. Each
> new request always asks psycopg to open a new one and the old one
> never
> used. AFAIK Apache alone can't magically provide connection pooling.
It's not pooling per se; i
Jacob Kaplan-Moss wrote:
>Now, it's not that closing these connections at the end of each
>request is bad per se, but it is the case that creating new
>connections to PostgreSQL is actually pretty expensive, and so
>reusing connections gives a small but measurable performance
>increase.
>
On Apr 4, 2006, at 4:43 PM, Luke Plant wrote:
> I'm nervous about committing this, because it might mess something up
> for someone else. Can anyone comment on the original version?
> (apologies in advance for the mangled diff).
I'm not so sure this is a good idea...
When PostgreSQL reports a i
Nebojsa Djordjevic <[EMAIL PROTECTED]> writes:
> Luke Plant wrote:
>> On Wednesday 05 April 2006 00:31, Adrian Holovaty wrote:
>>
>>> If that fixes the problem, go ahead and commit it -- it doesn't
>>> seem like the type of change that would cause problems. Thanks for
>>> catching this!
>> OK,
Luke Plant wrote:
> On Wednesday 05 April 2006 00:31, Adrian Holovaty wrote:
>
>> If that fixes the problem, go ahead and commit it -- it doesn't seem
>> like the type of change that would cause problems. Thanks for
>> catching this!
>
> OK, I've committed, and it seems to work fine. I've found
On Wednesday 05 April 2006 00:31, Adrian Holovaty wrote:
> If that fixes the problem, go ahead and commit it -- it doesn't seem
> like the type of change that would cause problems. Thanks for
> catching this!
OK, I've committed, and it seems to work fine. I've found one thing
that worries me t
On 4/4/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> OK, so I tried this out on a local Apache2 instance and got exactly the
> same thing. I found an oddity in the source code, and simplifying it
> (see below) fixed it for me in both instances, though I don't really
> know why.
>
> I'm nervous abou
On Tuesday 04 April 2006 21:52, Luke Plant wrote:
> I have an app that is live and running m-r (yeah, I know!), and I
> just got a "connection limit exceeded for non-superusers" error. It
> appears that connections are not being closed at all. With every hit
> I'm getting another entry in the pr
For me the same, hitting refresh a couple of times creates more and
more of those '[local] idle in transaction' things.
Rudolph
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
I have an app that is live and running m-r (yeah, I know!), and I just
got a "connection limit exceeded for non-superusers" error. It appears
that connections are not being closed at all. With every hit I'm
getting another entry in the process table, mainly of this form:
$ps -ef
postgres 20
22 matches
Mail list logo
