Skip to content

Replace PostgreSQL advisory locking with fenced leases - #1111

Open
joostjager wants to merge 3 commits into
lightningdevkit:mainfrom
joostjager:postgres-leases
Open

joostjager wants to merge 3 commits into
lightningdevkit:mainfrom
joostjager:postgres-leases

Conversation

@joostjager

@joostjager joostjager commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

Replace the temporary PostgreSQL advisory lock introduced in #1012 with a renewable lease in a companion table. The advisory-lock mechanism has not been released, so no migration is needed.

Acquire the lease atomically with schema setup, before loading persisted state. Validate ownership and expiry and renew the lease within each KV mutation transaction, so stale writes and deletes cannot commit. This replaces the separate lock checks before and after operations.

Renew idle leases in the background and release them by owner ID on drop. Lease loss panics in the calling task for mutations or in the background renewal task; background renewal errors and timeouts also panic. No recovery API or node lifecycle changes are introduced.

Tests cover setup rollback, contention, idle renewal, renewal timeouts, stale mutations, and release after takeover. Also verified contention, takeover after a crash, graceful restart, and stale-owner failure using two real LDK Server instances sharing a database.

@ldk-reviews-bot

ldk-reviews-bot commented Sep 21, 2026 •

Copy link
Copy Markdown

👋 Thanks for assigning @benthecarman 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.

@tnull tnull left a comment •

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs a rebase for CI to run. Let me know when fully ready for review.

@tnull tnull added this to the 0.8 milestone Sep 22, 2026
@joostjager

Copy link
Copy Markdown
Contributor Author

If we indeed add this on the 0.8 milestone, I'll remove the migration because the temp. locking solution won't be in a release.

@tnull

tnull commented Sep 23, 2026

Copy link
Copy Markdown
Collaborator

If we indeed add this on the 0.8 milestone, I'll remove the migration because the temp. locking solution won't be in a release.

Do it.

Create the KV table, record its schema version, and create the listing
index in one transaction so failed initialization rolls back schema
changes. Keep database creation outside the transaction and preserve the
session advisory lock for the store's lifetime.

Add a regression test that forces index creation to fail and verifies
the schema version update is rolled back.
Move pooled connection acquisition and query retry handling for writes
and removals into execute_mutation. Preserve advisory lock checks,
per-key write ordering, SQL, and error mapping so lease enforcement can
be added to the shared helper separately.
Replace the temporary session advisory lock with an expiring lease in a
companion table. Acquire it after schema setup and validate and renew it
after each KV mutation in the same transaction, so stale writes and
deletes roll back before commit.

Renew idle leases in the background and release them by owner ID on
drop. Explicitly panic on lease loss in the calling task or background
renewal task, and on background failure or timeout, without adding
recovery APIs.

Cover rejected setup rollback, repeated idle renewal, renewal timeouts,
stale writes and deletes, and releasing an old owner after takeover.
@joostjager
joostjager marked this pull request as ready for review September 23, 2026 12:21
@joostjager
joostjager removed the request for review from TheBlueMatt September 23, 2026 12:23
@joostjager

Copy link
Copy Markdown
Contributor Author

I’ve removed the migration. This now directly replaces advisory locks with the lease table.

I’m particularly happy to see all the scattered checks before and after operations to confirm we still hold the lock disappear. PostgreSQL now checks lease validity within the transaction.

I had a good back-and-forth with AI to minimize the diff. I think it’s looking pretty good now.

@joostjager
joostjager requested a review from tnull September 23, 2026 12:24

@tnull tnull left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, yet to do a very detailed review. Also tagging @benthecarman as a secondary reviewer as he did the first approach.

.execute(&update_sql, &[&self.lease_owner_id.as_slice(), &lease_duration_secs])
.await?;
if updated != 1 {
panic!("PostgreSQL node lease was lost; continuing may corrupt node state");

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably should be std::process:abort as panicking the tokio task won't abort the whole process, but just have the task return a JoinError in the end.

@joostjager joostjager Sep 24, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous advisory-lock implementation used assert! rather than abort, and LDK Server sets panic = "abort" for both dev and release builds. But definitely seems safer to use std::process:abort, will change.

Note that not panicking wouldn't be a data consistency issue, because the consistency is guarded in each transaction.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although, it seems in other places in ldk-node, it's not an explicit process abort?

@tnull
tnull requested a review from benthecarman September 24, 2026 12:41
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.

3 participants