Does Neon guarantees row level locks to be exclusive?

[rickchristie]

Hello Neon team,

I'm reading and trying to understand Neon architecture: https://neon.tech/docs/introduction/architecture-overview

According to my understanding (please correct me if I'm wrong), each of the Compute pods are running Postgres server. What happens when there are two row-level lock queries in two different transaction?

Tx1 -------> [Compute Pod A] (SELECT * FROM account WHERE Id = 5 FOR UPDATE)
             [Compute Pod B]
             [Compute Pod C]
Tx2 -------> [Compute Pod D] (SELECT * FROM account WHERE Id = 5 FOR UPDATE)

1. If row-level locks works according to Postgres documentation, how does Neon guarantee its exclusivity?
2. How and where is the queue coordinated? If there are more than 1 blocked transactions, which part of the system decides which transaction is next?

Thanks,

Rick

[knizhnik]

There is some misunderstanding. Yes, each compute = Postgres instance is running in separate Pod or VM.
It means that all Postgres backends (processes handling client requests) are launched i the same Pod or VM.
So it is more or less normal Postgres instance, just with cut-off storage layer. All backends are connected to the same shared memory.
Any synchronization between backends is performed as in vanilla Postgres. There is no any Neon specific here.
Different Pods are running different Postgres instances and never need to communicate with each other.

[hlinnaka]

Neon is a single-writer system, there can be only one writer compute pod at a time. Just like in a vanilla Postgres setup with replication. You can have read-only replicas, but you cannot run "SELECT FOR UPDATE" in a read-only node. Transaction handling and MVCC in Neon work the same as in any Postgres installation.

[yfzysxlg]

Hello ，Do many tenants share one writer compute pod？Thanks

[rickchristie]

Thanks @hlinnaka and @knizhnik - this clears up a lot! 🙇