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.

Reply via email to