| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Avoid overflow with simplehash |
| Date: | 2023-07-06 14:37:17 |
| Message-ID: | 637F10BC-EB05-4460-A10B-D690DEB1FC5C@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 6 Jul 2023, at 16:28, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> The function SH_START_ITERATE can trigger some overflow.
>
> See:
> typedef struct SH_ITERATOR
> {
> uint32 cur; /* current element */
> uint32 end;
> bool done; /* iterator exhausted? */
> } SH_ITERATOR;
>
> The cur field is uint32 size and currently can be stored a uint64,
> which obviously does not fit.
- Assert(startelem < SH_MAX_SIZE);
+ Assert(startelem < PG_UINT32_MAX);
I mighe be missing something, but from skimming the current code, SH_MAX_SIZE
is currently defined as:
#define SH_MAX_SIZE (((uint64) PG_UINT32_MAX) + 1)
Can you show a reproducer example where you are able to overflow?
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2023-07-06 14:42:17 | Re: Avoid overflow with simplehash |
| Previous Message | Amit Langote | 2023-07-06 14:29:10 | Re: generic plans and "initial" pruning |