TID Range Scans can return wrong results after scanning backwards - Mailing list pgsql-bugs

AI reported a bug (appended to this email) where TID Range Scans can
return the wrong results after changing the direction of the scan.

Regards,
    Jeff Davis



SQL repro
---------

    CREATE TABLE t (id int, data text) WITH (fillfactor = 10);
    -- 5 rows per page, 20 pages: ctids (0,1) .. (19,5)
    INSERT INTO t SELECT i, repeat('x', 100)
      FROM generate_series(1, 100) i;
    SET enable_seqscan = off;
    BEGIN;
    DECLARE c SCROLL CURSOR FOR
      SELECT ctid FROM t WHERE ctid >= '(2,1)' AND ctid <= '(11,5)';
    MOVE FORWARD 35 c;      -- cursor is now on (8,5)
    FETCH BACKWARD 2 c;     -- (8,4), (8,3): correct
    FETCH BACKWARD ALL c;   -- should return 32 rows, returns 12
    COMMIT;


Diagnosis
---------

heap_setscanlimits() stores the number of blocks to scan in
rs_numblocks. heapgettup_advance_block() then treats that field as a
remaining budget: it decrements it once for every block it hands out,
in either direction, and ends the scan when it reaches zero.  That
model only holds for a scan that moves in one direction and consumes
exactly the blocks it requests.  A change in direction breaks that.