On Wed, Oct 5, 2016 at 2:09 PM, Andres Freund wrote:
> On 2016-10-04 21:40:29 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2016-10-05 09:38:15 +0900, Michael Paquier wrote:
>> >> The existing interface of MemoryContextAlloc do not care much
On 2016-10-04 21:40:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-10-05 09:38:15 +0900, Michael Paquier wrote:
> >> The existing interface of MemoryContextAlloc do not care much about
> >> anything except Size, so I'd just give the responsability to the
> >>
Andres Freund writes:
> On 2016-10-05 09:38:15 +0900, Michael Paquier wrote:
>> The existing interface of MemoryContextAlloc do not care much about
>> anything except Size, so I'd just give the responsability to the
>> caller to do checks like queue != (Size) queue when queue
On 2016-10-05 09:38:15 +0900, Michael Paquier wrote:
> On Wed, Oct 5, 2016 at 8:56 AM, Andres Freund wrote:
> > That made me wonder if it's not actually a mistake for
> > MemoryContextAllocExtended() size parameter to be declared
> > Size/size_t. That prevents it from
On Wed, Oct 5, 2016 at 8:56 AM, Andres Freund wrote:
> That made me wonder if it's not actually a mistake for
> MemoryContextAllocExtended() size parameter to be declared
> Size/size_t. That prevents it from detecting such overflows, forcing
> code like the above on callsites.
Hi,
I was working on making sure that allocations for [1] don't overflow
size_t for large hash tables, when created on 32bit systems. I started
to write code like
if (sizeof(SH_CONTAINS) * (uint64) tb->size) !=
sizeof(SH_CONTAINS) * (size_t) tb->size))
{
elog(ERROR, "hash table too large