Repository navigation
next_notification: never wait less than 1 ms - #2
Merged
Merged
Conversation
may keeps park timeouts in whole milliseconds and, up to 0.3.51, truncates anything shorter to 0, which it reads as "no timeout". When the time left before next_notification's deadline fell under 1 ms (a caller waiting until a deadline, or a loop after a stale permit), the wait in a coroutine never returned. Round the wait up to 1 ms. Regression test: sub-millisecond timeouts in a coroutine return. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y3TSRmEZAYU6RBUXhkn7WF
casibbald
added a commit
that referenced
this pull request
Nov 2, 2026
The integration branch rebased onto upstream master 0f93c04, which now contains #2 (notification delivery), #3 (COPY IN deadlock) and #4 (CI). What upstream does not have, as one change; the tree is identical to the old integration head 3a24363, so consumers get exactly the code they ran: - TLS (rustls) with libpq sslmode, root CA and client certificates; explicit plaintext sslmode accepted - graceful shutdown on drop (close the socket), pending responses failed when the I/O loop exits, a 1 MiB stack for the connection coroutine - Client::is_closed, Client::next_notification (wakes LISTEN consumers; never waits less than 1 ms), RowStream affected-row count - Error::user_column_decode_failed - CopyInReceiver drops the unused recv method upstream kept - tests: severed connections, TLS, notifications; examples/leak_probe Per-commit history: tag integration-2026-11-02 (old head 3a24363). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y3TSRmEZAYU6RBUXhkn7WF
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
next_notificationcould hang forever in a coroutine when the time left before its deadline dropped under 1 ms: may (up to 0.3.51) stores park timeouts in whole milliseconds and truncates shorter ones to 0, which it reads as "no timeout". The wait is now rounded up to 1 ms.Found while switching LifeReflector to
next_notification: its leader waits until the next deadline, so sub-millisecond remainders were routine. The may side is fixed separately (microscaler/mayd74595b, merged to the fork's master in #3), but this keeps may_postgres safe on crates.io may.src/client.rs: the guard.tests/test/main.rs:next_notification_returns_for_sub_millisecond_timeouts(1 µs … 1.5 ms in a coroutine, bounded by a 10 s guard). It hangs without the fix.🤖 Generated with Claude Code
https://claude.ai/code/session_01Y3TSRmEZAYU6RBUXhkn7WF