An unlimited per-check limit stops downloads on Postgres #98

New Issue

rays · 2026-09-29T11:26:23-07:00

rays commented

2026-09-29 11:26:23 -07:00

With max_new_per_check set to 0 (unlimited) and no per-subscription limit, merge_policy's budget is usize::MAX, and Db::pending binds it as limit as i64, which is -1. SQLite reads LIMIT -1 as no limit; Postgres refuses it (LIMIT must not be negative), so the scan of that feed fails when it gets to its downloads. Production's limit is 3, so it is not hit today. Found reading pending() while looking at #97. Fix: clamp, limit.min(i64::MAX as usize) as i64.

With max_new_per_check set to 0 (unlimited) and no per-subscription limit, merge_policy's budget is usize::MAX, and Db::pending binds it as `limit as i64`, which is -1. SQLite reads LIMIT -1 as no limit; Postgres refuses it (LIMIT must not be negative), so the scan of that feed fails when it gets to its downloads. Production's limit is 3, so it is not hit today. Found reading pending() while looking at #97. Fix: clamp, `limit.min(i64::MAX as usize) as i64`.

rays added the bug label 2026-09-29 11:26:23 -07:00

rays referenced this issue from a commit

2026-09-29 11:37:40 -07:00

Clamp an unlimited download queue's LIMIT for Postgres (#98)

rays commented

2026-09-29 11:39:03 -07:00

Fixed in 4a26c73: pending() clamps the limit to i64::MAX before binding it. The new test fails on Postgres without it (LIMIT must not be negative) and passes with it; the whole suite passes on SQLite and Postgres. Deployed.

Fixed in 4a26c73: pending() clamps the limit to i64::MAX before binding it. The new test fails on Postgres without it (LIMIT must not be negative) and passes with it; the whole suite passes on SQLite and Postgres. Deployed.

rays closed this issue

2026-09-29 11:39:03 -07:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rays/ipx#98