I did some digging, and the reason for the error is this line in the
patch:
self.cursor.outputtypehandler = self._outputtypehandler
What is happening is that self has a reference to self.cursor, which
has reference to bound method self._outputtypehandler, which has a
reference to self. Thus, there is a reference loop, and garbage
collection is delayed. Changing the _outputtypehandler to @classmethod
seems to solve this problem.
The test case used was basically this: for i in range(10000):
SomeModel.objects.create(...)
While inspecting this issue I found out that if one iterates a
queryset partially, then the cursor will not be closed until gc. The
reason for this is that the queryset converts the rows from the db
into objects in batches, and if all of the rows aren't converted, then
the cursor is kept open. I have been toying with the idea of removing
the chunked object conversion from the queryset __iter__ (#18702)
which would remove the possibility of leaking cursors that way.
- Anssi
On 4 syys, 22:02, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> Resending to the list:
>
> On Sep 4, 2012 11:44 AM, "Ian Kelly" <ian.g.ke...@gmail.com> wrote:
>
> > On Mon, Sep 3, 2012 at 6:14 AM, Shai Berger <s...@platonix.com> wrote:
> > > On Wednesday 29 August 2012 22:17:22 Ian Kelly wrote:
>
> https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78c...
>
>
>
>
>
>
>
> > >> b83bd
>
> > > I've run a version based on this -- basically, porting the patch to
> Django 1.3
> > > which we use (so, no tzinfo), using "float" as the default for
> expressions, and
> > > putting the whole thing as a derived class from the original adapter
> rather
> > > than a patch (because that's what we do here, as we also need named
> parameters
> > > and we had to add them). I found that it leaks something -- the error
> says
> > > "cursors", but I suspect something more subtle; either way, this is
> what I got
> > > from a page which makes several hundred queries (don't ask):
>
> > Are these ORM queries or custom queries? If the latter, are you
> > explicitly closing the cursors? That should help prevent the issue,
> > although unfortunately the ORM doesn't do this. The cursors should be
> > closed anyway when they're finalized, but maybe we've got a reference
> > cycle preventing them from getting cleaned up right away, and too many
> > are accumulating between garbage collection passes.
>
> > When I've seen this error in the past, the immediate solution has been
> > to increase the OPEN_CURSORS parameter in the database. See:
>
> >http://www.orafaq.com/wiki/ORA-01000
>
> > Cheers,
> > Ian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
