LockNotAvailable: could not obtain lock on row in relation "stock_move"

Support Developer
1

Hi,
This error is becoming very common in our server:

 File "trytond/modules/stock/shipment.py", line 2994, in transition_start
    self.record.assign_try()
  File "trytond/modules/stock_lot/stock.py", line 476, in assign_try
    success = super().assign_try(moves, with_childs, grouping)
  File "trytond/modules/stock/move.py", line 986, in assign_try
    cls._assign_try_lock(
  File "trytond/modules/stock/move.py", line 1169, in _assign_try_lock
    cursor.execute(*query)
  File "trytond/backend/postgresql/database.py", line 68, in execute
    cursor.execute(self, sql, args)
LockNotAvailable: could not obtain lock on row in relation "stock_move"

Everytime it happens, I can see that there is a few users trying to assign moves at the same time frame, but I wonder if there is a way to manage this situations, not only to end users but also for administrators, as when It happens it is quite hard to identify what is going on in real time, and checking pg_locks does not help at all (note that I don’t have a problem of a transaction locking a table for ever, the problem gets fixed itself in a moment as the lock ends, but it is still annoying).
Could avoiding the nowait=True in Move._assign_try_lock be a good idea? i’d rather have users waiting for a while than constantly clicking a button which is not working.
Thanks.

2

This is expected error which is normally solved automatically when the lock of the other user is released.

Having said that, I think it will be great if we can show to the user some more meaningfull message to let them now about the logs instead just raising the traceback which makes them think there is something wrong in the error.

3

LockNotAvailable is a OperationalError error so it is retried according to the configuration.
On busy system, you may want to increase it.
Also the assignation process may be slow because there are too many stock moves. In this case you should consider using stock period.

No because any way the transaction must be restarted and there is still no guarantee to have the lock and also it will consume a database connection just to wait. It is better to wait without consuming a connection as PostgreSQL has a limited number of available connection.

4

I will take a look at this, thanks.

5

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.