Re: Removing "long int"-related limit on hash table sizes

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Removing "long int"-related limit on hash table sizes
Дата
Msg-id YP4gMZL9dcDL7Z49@paquier.xyz
обсуждение исходный текст
Ответ на Re: Removing "long int"-related limit on hash table sizes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Removing "long int"-related limit on hash table sizes
Список pgsql-hackers
On Sun, Jul 25, 2021 at 12:28:04PM -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> We really ought to just remove every single use of long.
>
> I have no objection to that as a long-term goal.  But I'm not volunteering
> to do all the work, and in any case it wouldn't be a back-patchable fix.
> I feel that we do need to do something about this performance regression
> in v13.

Another idea may be to be more aggressive in c.h?  A tweak there would
be dirtier than marking long as deprecated, but that would be less
invasive.  Any of that is not backpatchable, of course..

> No, I don't like that.  Using size_t for memory-size variables is good
> discipline.  Moreover, I'm not convinced that even with 64-bit ints,
> overflow would be impossible in all the places I fixed here.  They're
> multiplying several potentially very large values (one of which
> is a float).  I think this is just plain sloppy coding, independently
> of which bit-width you choose to be sloppy in.

Yeah, using size_t where adapted is usually a good idea.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fix memory leak when output postgres_fdw's "Relations"
Следующее
От: Greg Nancarrow
Дата:
Сообщение: Re: Added schema level support for publication.