I tried to search for "patch" and I got a list of 10071 issues, with no errors. I'm therefore closing this.

> It has a title "Templating Error" and wonder if SQL result is stored in memory
> before output? In this case is it possible to modify templating engine to allow
> streaming content directly from DB query?

That's not the problem at all. If you look at the true exception, you'll
notice

    self.db.cursor.execute(sql, tuple([int(row[0]) for row in r]))
ProgrammingError: ERROR:  stack depth limit exceeded
HINT:  Increase the configuration parameter "max_stack_depth".

This is a true error from postgres, and has nothing to do with the
template engine (and whether it's computing the result in memory).
Apparently, Postgres cannot properly support an "in" clause with
a large enumeration of literal values.

It shows up as a templating error, because the query is (indirectly)
invoked in the template, and because of the postgres exception, the
template cannot be rendered.

As I said, I worked around it by increasing postgresql's
max_stack_depth, from 2MB (which it was) to 7MB (which is the
recommended 1M less than `ulimit -s`). As I also said, this part
of SQL usage should probably be rewritten.

Error output is in attach in python bugtracker
http://bugs.python.org/file10887/bugs.python.org.txt

It has a title "Templating Error" and wonder if SQL result is stored in memory
before output? In this case is it possible to modify templating engine to allow
streaming content directly from DB query?

I have now worked around this by setting max_stack_depth to 7000 in the postgres
configuration. I think it would be better if roundup issued a different
postgresql statement, although I'm not sure how that could look like.

As accidentally reported in the main tracker, if you search for ``patch``, you
end up with a template error about recursion depth. I suspect too many issues
have the word 'patch' in them and Python's own recursion limit is being hit (or
something). Not sure if there is really anything we can do.