Re: Can rs_cindex be < 0 for bitmap heap scans?

Ranier Vilela <ranier.vf@gmail.com>

From: Ranier Vilela <ranier.vf@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Tomas Vondra <tv@fuzzy.cz>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-12-19T12:29:27Z
Lists: pgsql-hackers
Em qua., 18 de dez. de 2024 às 23:50, Richard Guo <guofenglinux@gmail.com>
escreveu:

> On Thu, Dec 19, 2024 at 8:18 AM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> > I pushed the straightforward option for now so that it's fixed.
>
> I think this binary search code now has a risk of underflow.  If 'mid'
> is calculated as zero, the second 'if' branch will cause 'end' to
> underflow.
>
> Maybe we need to do something like below.
>
> --- a/src/backend/access/heap/heapam_handler.c
> +++ b/src/backend/access/heap/heapam_handler.c
> @@ -2600,7 +2600,11 @@ SampleHeapTupleVisible(TableScanDesc scan, Buffer
> buffer,
>             if (tupoffset == curoffset)
>                 return true;
>             else if (tupoffset < curoffset)
> +           {
> +               if (mid == 0)
> +                   return false;
>                 end = mid - 1;
> +           }
>             else
>                 start = mid + 1;
>         }
>
> Alternatively, we can revert 'start' and 'end' to signed int as they
> were before.
>
How would it be *signed*?
Wouldn't overflow happen in this case?
rs_tuples now can be

UINT_MAX       = 4294967295

best regards,
Ranier Vilela

Commits

  1. Fix overflow danger in SampleHeapTupleVisible(), take 2

  2. Fix overflow danger in SampleHeapTupleVisible()

  3. Make rs_cindex and rs_ntuples unsigned