Обсуждение: 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