Skip to content

Add PostgreSQL node failover leases - #1000

Open
joostjager wants to merge 1 commit into
lightningdevkit:mainfrom
joostjager:postgres-node-failover
Open

Add PostgreSQL node failover leases#1000
joostjager wants to merge 1 commit into
lightningdevkit:mainfrom
joostjager:postgres-node-failover

Conversation

@joostjager

Copy link
Copy Markdown
Contributor

Addresses #932 by adding minimal active/passive failover support for nodes using the built-in PostgreSQL store.

PostgresStore acquires an exclusive lease for its KV table, renews it in the background, and fences every mutation by validating and renewing the lease in the same transaction. Lease loss is terminal for the node and is exposed to the application (ldk-server) so the process can exit and restart from persisted state.

This initial implementation is intentionally limited to PostgreSQL. Generic stores and VSS are out of scope. The API, timing configuration, and backend support can be extended later if operational experience requires it.

@joostjager
joostjager requested a review from tnull July 22, 2026 14:14
@ldk-reviews-bot

ldk-reviews-bot commented Jul 22, 2026

Copy link
Copy Markdown

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@joostjager

joostjager commented Jul 22, 2026

Copy link
Copy Markdown
Contributor Author

I’m primarily looking for a concept ACK on the overall direction at this stage. The code has already gone through several iterations, and it will probably need another pass once we agree that the lease, fencing, and process-exit approach is the right path.

ldk-server branch I've been testing with: lightningdevkit/ldk-server@main...joostjager:ldk-server:postgres-node-failover

Make PostgresStore acquire a table-scoped lease during construction
and fence every mutation with it. Treat runtime lease loss as
process-fatal so servers can exit without final persistence and
restart from durable state.
@joostjager
joostjager force-pushed the postgres-node-failover branch from 629386d to 056be7a Compare July 22, 2026 14:17
@benthecarman

Copy link
Copy Markdown
Contributor

Would be nice if this is abstracted out to also work with VSS. That way multi-device with a VSS backend can work

@joostjager

Copy link
Copy Markdown
Contributor Author

The safety-critical part seems mostly backend-specific to me, since lease validation and the KV mutation must be atomic within the backend. What layer of this do you envision abstracting?

If generalizing this later would not require much rewriting, I would prefer to leave any necessary code movement to a future VSS lease PR.

@joostjager

Copy link
Copy Markdown
Contributor Author

Friendly ping @tnull. I would like to agree on the overall approach before doing further implementation cleanup. If you do not currently have the bandwidth to take a look, please let me know too.

@tnull

tnull commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator

Friendly ping @tnull. I would like to agree on the overall approach before doing further implementation cleanup. If you do not currently have the bandwidth to take a look, please let me know too.

I'll try to get back to a first look some time this week, but review on PRs for v0.8 has priority right now.

I think to begin with my first question is whether we don't need a more general version of this anyways, i.e., something a Node wrapper that allows to safely shutdown/restart the node when connectivity drops and we need to safely restart the node on persistence failures.

@joostjager

joostjager commented Jul 27, 2026

Copy link
Copy Markdown
Contributor Author

whether we don't need a more general version of this anyway

For an initial version, I think rebuilding can remain the responsibility of the infrastructure, for example Kubernetes. ldk-node reports the lease lost, ldk-server exits, and the infrastructure restarts the process.

The wrapper you propose seems quite a bit broader, and I do not think it is needed to meet the initial objective of failover? As mentioned in #1000 (comment), making lease+mutation atomic is backend-specific, so a general wrapper would not replace that work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants