Hi there! This is somehow related to this other topic [1], which I have closed because I've found some new evidence and I though it would be better to open a new topic.
I'm having this problem where a simple select on auth_user table hangs indefinitely, until timeout. The problem occurs in one specific user account. The user logs in, but after the successfull login, any request hangs. I checked the postgres long running queries and I see this query hanging until timeout: SELECT auth_user.id, auth_user.first_name, auth_user.last_name, auth_user. email, auth_user.password, auth_user.registration_key, auth_user. reset_password_key, auth_user.registration_id, auth_user.alta,auth_user. plantel, auth_user.responsable, auth_user.nombre, auth_user.telefono, auth_user.autor, auth_user.foto, auth_user.foto_temp, auth_user.moderador, auth_user.descripcion, auth_user.facebook,auth_user.twitter, auth_user. linkedin, auth_user.gplus FROM auth_user WHERE (auth_user.id = 2) LIMIT 1 OFFSET 0; As you see, the query is a simple select to the auth_user table. Also, notice that it uses LIMIT, so it retrieves one only row. Additionally, I can confirm that the table has only four rows. I went a little further, and I checked the pg_locks at postgres when the problem is happening (that is, during the 60 seconds until timeout). This is the query I run to check the locks and this is what I see during that time: select t.relname,l.locktype,page,virtualtransaction,pid,mode,granted from pg_locks l, pg_stat_all_tables t where l.relation=t.relid order by relation asc; relname | locktype | page | virtualtransaction | pid | mode | granted -----------------------------+----------+------+--------------------+------+-----------------+--------- pg_class | relation | | 70/908027 | 4421 | AccessShareLock | t pg_index | relation | | 70/908027 | 4421 | AccessShareLock | t pg_namespace | relation | | 70/908027 | 4421 | AccessShareLock | t web2py_session_infosanpedro | relation | | 16/1858255 | 9865 | AccessShareLock | t auth_user | relation | | 16/1858255 | 9865 | AccessShareLock | t (5 rows) *Notice the lock of the web2py_session_* and auth_user tables.* *That lock is there during the whole 60 seconds, until timeout*. After timeout, the lock isn't there anymore. If I reload the page, again, the lock appears and the request hangs until timeout. All the other user accounts can login normally. Also, there is nothing particularly different with the user account having the problem (it's an account like any other else). Of course, I already tried to delete everything from the web2py_session table, but it doesn't work, the problem remains. Where else should I look? Would it help if I share with you the app code for the login? It doesn't do any tricky stuff. What concerns me is that the problem is generated in one specific account, but in several of our customers (we have the same web2py app installed for every one of our customers, each one has its own database). The same problem is happening randomly in a few accounts. Database activity is really low. I'm pretty lost here, so any help or suggestion will be appreciated. Thanks in advance. Regards, Lisandro [1] https://groups.google.com/forum/#!topic/web2py/o0FBeimrr5c -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.