RowLock and multiple transactions
Hi,
when "SELECT .. WHERE .. FOR NO KEY UPDATE" is used synchronize access,
and the transaction holding the lock completes, how does PostgreSQL
decide /which one/ of multiple waiting transactions will the lock be
granted to next?
In my testing (on Ubuntu 16.1-1.pgdg20.04+1, 64bit) with a real-world
application (that acquires multiple locks on a number of relations) it
seems that it is always the transaction that attempted to lock _last_ ... ?
I thought that would most probably be random, or if it was not, the
order would have been explained in the docs?
Thank you for any insights...
Best regards
-hannes
On Wed, 2024-02-14 at 23:52 +0100, Hannes Erven wrote:
when "SELECT .. WHERE .. FOR NO KEY UPDATE" is used synchronize access,
and the transaction holding the lock completes, how does PostgreSQL
decide /which one/ of multiple waiting transactions will the lock be
granted to next?In my testing (on Ubuntu 16.1-1.pgdg20.04+1, 64bit) with a real-world
application (that acquires multiple locks on a number of relations) it
seems that it is always the transaction that attempted to lock _last_ ... ?
I thought that would most probably be random, or if it was not, the
order would have been explained in the docs?
Transactions queue behind a lock, and they get the lock in a "first come,
first served" order.
Yours,
Laurenz Albe