On Nov 24, 2014, at 3:36 AM, Rick van Hattem <wo...@wol.ph> wrote: > If you fetch N+1 items you know if there are over N items in your list.
Let's stop there. Unfortunately, because of the way libpq works, just sending the query and checking the result set size won't solve your problem, except for an even smaller edge case. Using the standard (non-named-curosr) protocol, when you get the first result back from libpq, *every result* is sent over the wire, and takes up space on the client. Thus, no limitation on the client side (number of Django objects created, number of Python objects created by psycopg2) will prevent an out-of-memory error. In my experience (and I've seen this problem a lot), the OOM occurs on the libpq results, not on the other parts. Thus, the proposal only solves the relatively narrow case where the libpq result does *not* create an OOM, but creating the Django and psycopg2 objects does. I'll note also that it's not that server that dies in this case; the particular thread doing the request gets an exception. -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/81A38D7E-E355-46D1-9C21-1C7D43BCC648%40thebuild.com. For more options, visit https://groups.google.com/d/optout.
