Re: Avoid overflow with simplehash
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ranier Vilela <ranier.vf@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2023-07-06T15:27:33Z
Lists: pgsql-hackers
Hi, On 2023-07-06 11:16:26 -0400, Tom Lane wrote: > Ranier Vilela <ranier.vf@gmail.com> writes: > > See the comments: > > "Search for the first empty element." > > If the empty element is not found, startelem has PG_UINT64_MAX value, > > which do not fit in uint32. > > I think the point of that assertion is exactly that we're required to > have an empty element (because max fillfactor is less than 1), > so the search should have succeeded. Right, that part of the proposed change seems bogus to me. > It does seem like we could do > > uint64 startelem = SH_MAX_SIZE; > > ... > > Assert(startelem < SH_MAX_SIZE); > > which'd make it a little clearer that the expectation is for > startelem to have changed value. I guess? I find it easier to understand all-bits-set in a coredump as too-large than SH_MAX_SIZE, but ... > And I agree that declaring "i" as int is wrong. Yea, that's definitely not right, not sure how I ended up with that. Will push a fix. I guess it should be backpatched... Greetings, Andres Freund
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