Hi, You are right indeed. I had a special case lurking deep in my code that made a write query on the muxes table. Of course, my stubborn head was certain that I had no such thing and hence I used a lot of time chasing ghosts :)
Is it possible to detect that you are waiting for locks to improve the error message (I guess not, the c library probably just sits there until it gets the lock)? I'd probably figured this by myself with a better error message. I guess such an error message should be given by postgreSQL.. the "FATAL: 08P01: invalid frontend message type 32" isn't exactly helpful :) Anyway, the problem is solved and I'm happy. Thanks a lot, Frederik On 10/23/06, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > Hi Frederik, > > this sounds more like your "outer" process has a transaction running on > the table "muxes" that is locking the table from updates, so the "inner" > process waits for ever. What happens when you issue a "commit" before > starting the inner process? > > -- Christoph > > > > _______________________________________________ > PyGreSQL mailing list > [email protected] > http://mailman.vex.net/mailman/listinfo/pygresql > -- Time was invented by carbon based lifeforms in order to monitor their ongoing decay _______________________________________________ PyGreSQL mailing list [email protected] http://mailman.vex.net/mailman/listinfo/pygresql
