Lock Postgres stores on initialization - #1012
Conversation
Prevent multiple nodes from opening the same PostgreSQL database table at once while allowing separate database and table pairs to coexist. Retain the session-scoped advisory lock for the store lifetime. This change was created with OpenAI Codex.
|
👋 Thanks for assigning @joostjager as a reviewer! |
| pool: SmallPool, | ||
| // PostgreSQL advisory locks are session-scoped, so keep the connection that acquired our lock | ||
| // alive for the lifetime of the store. | ||
| _lock_client: ClientConnection, |
There was a problem hiding this comment.
[P1] Fail closed when the lock session disconnects
This client is retained but never monitored. If its PostgreSQL session ends, the advisory lock is released while the independent pool can reconnect and continue serving operations. A second store can then acquire the lock while this store resumes writing. Please treat lock-session loss as terminal before any further operation, or otherwise reacquire and validate ownership without allowing stale writes. A regression test should terminate this backend, start a replacement store, and verify that the original store cannot operate.
|
@joostjager Mind sharing again why you think this PR is not sufficient for a first stopgap measure for v0.8/LDK Server v0.1? From a first impression it looks like the kind of minimally invasive thing we want to land right now, before we can then take time to discuss the right approach / review #1000 etc. |
4 participants
If we aren't going to get #1000 in before the release, we can add a simple lock on the postgres using its native
pg_try_advisory_lock.Prevent multiple nodes from opening the same PostgreSQL database table at once while allowing separate database and table pairs to coexist. Retain the session-scoped advisory lock for the store lifetime.