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.
