:o( The situation is this - I have a database-driven website that backs onto a Postgres 7.1RC1 server - this does not affect the problem, the same thing happens with a 7.0.3 and 7.0.2 server on either the same or different machines. I have tried using PoPy/ZPoPyDA or psycopg/ZPsycopgDA - the same problem occurs with both. I have been able to reproduct this on a minimal install of 2.3.1 (no other products). What's happening - I have a PythonScript that does this: m = container.machine.SQL_get(machineid=machineid)[0] print container.machine.show_html(context,REQUEST, param1=m.param1, param2=m.param2, param3=m.param3, param4=m.param4, param5=m.param5, param6=m.param6, param7=m.param7, param8=m.param8, param9=m.param9, param0=m.param0) return printed show_html is a DTML document. When called at "high" speed (2-3 times a second) by URL traversal (i.e. GETing http://site.name/Zope/path/pythonscript?machineid=whatever) this causes either (in order of likelihood): 1) The 4 child threads of ZServer to die, leaving only the top-level and child thread, and a core file 2) *One* of the child threads to die, causing the rest of Zope to completely hang (hung inside a SIGSTOP) 3) The entire thing to bomb out *But*, if I reduce the number of named parameters to the DTML method (when of course it doesn't render properly) then everything's OK. The current code dies if there are >8 named parameters. But it seems to vary. I thought that the parameters had to be records from an SQL query, but now I'm not so sure. If anyone has any ideas, I'd be glad to hear them. Failing that, I'm giving up :o) Regards, Phil +----------------------------------+ | Phil Mayers, Network Support | | Centre for Computing Services | | Imperial College | +----------------------------------+