Yes, in fact, I've been running that SQL command to check for locks, and 
sometimes I see that lock on other tables, but that other locks live for 
less than a second. However, when the problem happens, the lock on the 
auth_user and web2py_session tables remains there for the whole 60 seconds. 

Forgot to mention that, when the problem presents in an specific account, I 
can experience the same problem if I try to impersonate that account. It 
seems as if something would have "break" within that account, and deleting 
web2py_session_* rows doesn't help. Actually, until now, the only way I 
could "solve" it was creating a new account (of course, that is not 
technically a solution) or moving the sessions to Redis.

In case it helps, this is the controller function that processes the post 
for the login.
I don't pretend you check all the code, because I'm not sure how this could 
be the problem. 

def user():
    if request.env.request_method == 'POST':
        email = if else ''
        password = request.post_vars.password
        recordarme = bool(int(request.post_vars.recordarme or 0))
        errores = []
        if not email:
    errores.append(['email', 'Ingresa tu dirección de email'])
if not password:
    errores.append(['password', 'Ingresa tu contraseña'])
        if errores:
            return response.json({'success': False, 'errores': errores})

        usuario = db( == email).select().first()
        if not usuario:
            session.failed_login_attempt = True
            return response.json({
                'success': False,
                'message': 'Login data invalid'
        elif usuario.registration_key:
            return response.json({
                'success': False,
                'message': 'Registration is pending for confirmation'
            usuario = auth.login_bare(, password)
            if not usuario:
                return response.json({
                    'success': False,
                    'message': 'Login data invalid'
            session.auth.expiration = auth.settings.expiration
            if recordarme:
                session.auth.expiration = auth.settings.long_expiration
                session.auth.remember_me = True
                if response.cookies.get(response.session_id_name):
                    response.cookies[response.session_id_name]["expires"] = 
                                     origin='auth', description='User %s 
Logged-in' %
            return response.json({'success': True})

El jueves, 5 de abril de 2018, 17:42:46 (UTC-3), Anthony escribió:
> For any select that takes place within a transaction, Postgres by default 
> automatically acquires an access share lock on the involved tables, so this 
> should be happening on all requests. However, access share locks do not 
> conflict with each other, so I don't think these locks are necessarily the 
> source of your problem.
> Anthony
> On Thursday, April 5, 2018 at 10:58:07 AM UTC-4, Lisandro wrote:
>> 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.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 ( = 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]!topic/web2py/o0FBeimrr5c

- (Documentation)
- (Source code)
- (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 
For more options, visit

Reply via email to