We should come up with a better algorithm to handle advisory locks. Currently, they pin the client to the server connection. That's a bit simplistic. We can do something similar to LISTEN/NOTIFY, e.g., take the lock on dedicated connection, while continuing to multiplex.
Some careful design decisions are needed here:
pg_advisory_lock needs to block until that lock is released, so some synchronization between clients is needed- It also needs to block if that lock is taken by another PgDog process, so synchronization between PgDog's is neeeded
So overall, not a trivial feature, but certainly interesting.
TLDR: build a distributed locking mechanism using Postgres as the broker.
We should come up with a better algorithm to handle advisory locks. Currently, they pin the client to the server connection. That's a bit simplistic. We can do something similar to
LISTEN/NOTIFY, e.g., take the lock on dedicated connection, while continuing to multiplex.Some careful design decisions are needed here:
pg_advisory_lockneeds to block until that lock is released, so some synchronization between clients is neededSo overall, not a trivial feature, but certainly interesting.
TLDR: build a distributed locking mechanism using Postgres as the broker.