Re: TID Range Scans can return wrong results after scanning backwards

On Thu, 17 Sept 2026 at 19:14, Ewan Young <kdbase(dot)hack(at)gmail(dot)com> wrote:
> The attached patch treats the limit as a fixed window of rs_numblocks
> blocks starting at rs_startblock instead of a budget: the forward
> direction ends when it reaches the block just past the window, and the
> backward direction already ends at rs_startblock, since
> heapgettup_initial_block() starts a backward scan at the window's last
> block. rs_numblocks is no longer modified during the scan. TID Range
> Scans are the only caller that scans a limited range in both
> directions, so other heap_setscanlimits() users see no change.

I adjusted this and wrote the version for the backbranches (block
advancing is different pre-v16) and pushed it.

For the record, you really need to sense-check your LLM-generated
comments in the future. If patch authors don't check this sort of
stuff, then I really fail to see the point of posting these simple bug
fix patches. I really was unable to parse the "started us at its last
block" in the following:

+ * We're done if the last block is the start position. This also
+ * covers the limit imposed by heap_setscanlimits(), since the window
+ * begins at rs_startblock and heapgettup_initial_block() started us
+ * at its last block.

Anyway, I rewrote that into something that I could understand.

For the tests, I think they were far too verbose. I added some extra
MOVEs to make it so the expected results weren't as large.

David