Re: Avoid overflow with simplehash

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Avoid overflow with simplehash
Дата
Msg-id 20230706173324.hn7t6khiygu6jxqe@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Avoid overflow with simplehash  (Ranier Vilela <ranier.vf@gmail.com>)
Ответы Re: Avoid overflow with simplehash
Список pgsql-hackers
Hi,

I pushed changing i to uint32 and adding Tom's comment to 11-HEAD.


On 2023-07-06 14:01:55 -0300, Ranier Vilela wrote:
> > > then will it iterate forwards?
> >
> > No, it'd still iterate backwards, but starting from the wrong place - but
> > there is no correct place to start iterating from if there is no unused
> > element.
> >
> Thanks for the confirmation.
> 
> So I suppose we could have this in v1, attached.
> With comments added by Tom.


> diff --git a/src/include/lib/simplehash.h b/src/include/lib/simplehash.h
> index 48db837ec8..4fe627a921 100644
> --- a/src/include/lib/simplehash.h
> +++ b/src/include/lib/simplehash.h
> @@ -964,8 +964,8 @@ SH_DELETE_ITEM(SH_TYPE * tb, SH_ELEMENT_TYPE * entry)
>  SH_SCOPE void
>  SH_START_ITERATE(SH_TYPE * tb, SH_ITERATOR * iter)
>  {
> -    int            i;
> -    uint64        startelem = PG_UINT64_MAX;
> +    uint32        i;
> +    uint32        startelem = PG_UINT32_MAX;

The startelem type change doesn't strike me as a good idea.  Currently
PG_UINT32_MAX is a valid element.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: pgsql: Fix search_path to a safe value during maintenance operations.
Следующее
От: Gurjeet Singh
Дата:
Сообщение: Re: MERGE ... RETURNING