could not obtain lock on row in relation "res_users"

[risto3]

I received a number of these with the

2012-03-08 13:00:58,104 18563 ERROR ? openerp.sql_db: bad query: SELECT id from res_users
                          WHERE login='admin' AND password='admin'
                                AND active FOR UPDATE NOWAIT
Traceback (most recent call last):
  File "/home/richard/src/openerp/server/6.1/openerp/sql_db.py", line 212, in execute
    res = self._obj.execute(query, params)
OperationalError: could not obtain lock on row in relation "res_users"

[Jignesh Rathod(OpenERP) (jir-openerp)]

Hello risto3,

I have checked this issue with latest trunk as well as 6.1 but
I did not face any problem like you mention in bug report .
So would you please provide more information with steps
regarding this issue .

Thanks and waiting for reply

[risto3 (risto3)]

Thinking back, this happened around the time a number of other issues were happening. Is it possible that the db was in an inconsistent state? I start out with a fresh db now when unsure.

What's the tool to "verify' (openerp-wise) the structure and contents of a db ?

Again, if it crops up again, I'll try to decorticate the problem a bit more.

[Jignesh Rathod(OpenERP) (jir-openerp)]

Hello risto3,

As per your comment #2 , Currently I am closing this issue.
If you find out the proper way to reproduce this issue
then you can reopen this issue with more information .

Thank you!

[Marcel van der Boom (HS-Development BV) (mrb)]

I ran into this same issue. What I did was accessing the calendars collections from thunderbird. It seems that it occurs when things get 'busy' for lack of a better word.

The problem dissapears when access to the database get less again.

It is reproduceable on our end reliably by doing a 'sync remote calendars' with 3 or more calendars defined in thunderbird.

[Jignesh Rathod(OpenERP) (jir-openerp)]

Hello Marcel van,

I have checked this issue again at my end .I did not face traceback as mention
in bug discription. I have 'sync remote calendars' with 3 or more calendars
defined in thunderbird. It give me a traceback like ....

2012-05-01 23:43:27,179 21080 ERROR ? openerp.sql_db: bad query: UPDATE res_users
                        SET date=now() AT TIME ZONE 'UTC'
                        WHERE id=1 AND password=E'$1$lpCf4bge$1jipE0iiK8/.d6TJR2ZmV.' AND active
                        RETURNING id
Traceback (most recent call last):
  File "/home/jir/workspace/trunk6/server/openerp/sql_db.py", line 212, in execute
    res = self._obj.execute(query, params)
TransactionRollbackError: could not serialize access due to concurrent update

2012-05-01 23:43:27,180 21080 ERROR ? netsvc: Could not authenticate
Traceback (most recent call last):
  File "/home/jir/workspace/trunk6/addons/base_crypt/crypt.py", line 180, in login
    return self._login(cr, db, login, password)
  File "/home/jir/workspace/trunk6/addons/base_crypt/crypt.py", line 218, in _login
    (int(id), encrypted_pw.encode('utf-8')))
  File "/home/jir/workspace/trunk6/server/openerp/sql_db.py", line 152, in wrapper
    return f(self, *args, **kwargs)
  File "/home/jir/workspace/trunk6/server/openerp/sql_db.py", line 212, in execute
    res = self._obj.execute(query, params)
TransactionRollbackError: could not serialize access due to concurrent update

As bug : lp:992525

So would you please provide a more information regarding this issue.

Thanks and waiting for reply!

[Marcel van der Boom (HS-Development BV) (mrb)]

Not sure what extra info to provide. The error still occurs. On my test install I do not have base_crypt installed, which may explain the difference in queries?

We have a small number of testusers (4 at the moment). It may be the case that this bug is another manifestation ofof bug lp:992525

[Marcel van der Boom (HS-Development BV) (mrb)]

Jignesh,

Can you specify what extra info you need from me? We are still getting these errors on the server whenever a thunderbird client starts up.

[charton Jérémie (jcharton)]

Hi Guys.
I'm facing the same problem.
Openerp 6.1, using caldav with thundirbird (for calendars) and lightning (for tasks)
THE PASSWORD IN LOG IS NOT CRYPTED !!!! (COULD BE A BIG SECURITY ISSUE)

2012-11-20 11:21:41,596 13057 WARNING ? webdav: Cannot calculate own address: '_fileobject' object has no attribute 'getsockname'
2012-11-20 11:21:41,597 13057 INFO ? werkzeug: 81.248.44.73 - - [20/Nov/2012 11:21:41] "PROPFIND /webdav/GuyacomDev/calendars/users/isabelle/c/Tasks/ HTTP/1.1" 401 -
2012-11-20 11:21:41,634 13057 WARNING ? webdav: Cannot calculate own address: '_fileobject' object has no attribute 'getsockname'
2012-11-20 11:21:41,635 13057 INFO ? werkzeug: 81.248.44.73 - - [20/Nov/2012 11:21:41] "PROPFIND /webdav/GuyacomDev/calendars/users/isabelle/c/Meetings/ HTTP/1.1" 401 -
2012-11-20 11:21:42,036 13057 WARNING ? webdav: Cannot calculate own address: '_fileobject' object has no attribute 'getsockname'
2012-11-20 11:21:42,036 13057 INFO ? openerp.service.http_server: Found user="isabelle", passwd="***" for db="GuyacomDev"
2012-11-20 11:21:42,044 13057 WARNING ? webdav: Cannot calculate own address: '_fileobject' object has no attribute 'getsockname'
2012-11-20 11:21:42,044 13057 INFO ? openerp.service.http_server: Found user="isabelle", passwd="***" for db="GuyacomDev"
2012-11-20 11:21:42,046 13057 ERROR ? openerp.sql_db: bad query: SELECT id from res_users
                          WHERE login='isabelle' AND password='isabelle'
                                AND active FOR UPDATE NOWAIT
Traceback (most recent call last):
  File "/opt/openerp/server/openerp/sql_db.py", line 212, in execute
    res = self._obj.execute(query, params)
OperationalError: could not obtain lock on row in relation "res_users"

Charton Jérémie
Société Guyacom
French Guiana

[Eric Caudal - www.elico-corp.com (elicoidal)]

password is not crypted because you do not use the module base_crypt.

[charton Jérémie (jcharton)]

ok thanks Eric,

But the password thing is not why I reported this, just wanted to solve my caldav & thunderbird issues.

Thanks anyway, could be useful to know how to crpyt password in partner's production cases.