I would not think that behavior would extend to lock_timeout based on the explanation on stackexchange. I would assume that the potentially long runtime in this function is mostly in acquiring the lock and not doing the update given the implied primary key in the where clause, so perhaps lock_timeout would fit the need.
Or perhaps this is a much-simplified example and the real problem is not apparent. Why take an exclusive lock on an entire table to update a single row? What is this locks table for? Would advisory locks be the proper solution to the root problem perhaps? Just throwing things out there since context was lacking in the original question. https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-LOCK-TIMEOUT >
