How does Postgresql implement row locks and what are the performance impacts?

Question

I'm trying to understand how Postgresql under the hood is implementing a row lock so that I understand what resource implication this has.

If there are two database transactions. One of them has locked a row. The other database transaction is waiting to release the lock on that row. The transaction which is waiting for the release what resources will this consume?

Background: I would like to understand whether the waiting has a real impact on the resource consumption or whether such a lock situation provides just slow responses to the client.

• gidds: "The other database transaction is waiting to release the lock on that row." — do you mean ‘...waiting for the lock on that row to be released’? As written it implies that the other transaction already has that lock (which can't be true).
• Thomas Hunziker: I mean that one transaction is waiting for the other to release the lock. I do not talk about a deadlock situation.

Answer 1

The waiting session will hold on to all memory resources it's acquired so far; it will consume very little CPU, sleeping while waiting on the lock; and no I/O.

• Laurenz Albe: PostgreSQL does not spin on the lock, otherwise fine.
• Thomas Hunziker: @mustaccio: Does this apply as well when the database waits due to the transaction isolation level?