Re: Avoid overflow with simplehash
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2023-07-06T15:05:01Z
Lists: pgsql-hackers
Em qui., 6 de jul. de 2023 às 12:00, Daniel Gustafsson <daniel@yesql.se> escreveu: > > On 6 Jul 2023, at 16:42, Ranier Vilela <ranier.vf@gmail.com> wrote: > > Em qui., 6 de jul. de 2023 às 11:37, Daniel Gustafsson <daniel@yesql.se > <mailto:daniel@yesql.se>> escreveu: > > > #define SH_MAX_SIZE (((uint64) PG_UINT32_MAX) + 1) > > This is Assert, that is, in production this test is not done. > > Correct, which implies that it's a test for something which is deemed > highly > unlikely to happen in production. > Highly improbable does not mean impossible, or that it will never happen. > > If the empty element is not found, startelem has PG_UINT64_MAX value, > > which do not fit in uint32. > > Can you show an example where the hash isn't grown automatically to > accomodate > this such that the assertion is tripped? > A demo won't change the fact that the function can fail, even if it isn't currently failing. As a precaution to avoid future bugs, I think it's necessary to apply the patch to increase the robustness of the function. regards, Ranier Vilela
Commits
-
Fix type of iterator variable in SH_START_ITERATE
- 9f236198c31d 12.16 landed
- 6143602ebaab 11.21 landed
- 1508b57d4b7a 14.9 landed
- 09391ddc9578 13.12 landed
- d12d1a9278df 15.4 landed
- 727d96511ef5 16.0 landed
- f0a94d81e4f7 17.0 landed