Re: [HACKERS] Move allocation size overflow handling to MemoryContextAllocExtended()?

2016-10-07 Thread Robert Haas
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

Re: [HACKERS] Move allocation size overflow handling to MemoryContextAllocExtended()?

2016-10-05 Thread Andres Freund
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 > >>

Re: [HACKERS] Move allocation size overflow handling to MemoryContextAllocExtended()?

2016-10-04 Thread Tom Lane
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

Re: [HACKERS] Move allocation size overflow handling to MemoryContextAllocExtended()?

2016-10-04 Thread Andres Freund
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

Re: [HACKERS] Move allocation size overflow handling to MemoryContextAllocExtended()?

2016-10-04 Thread Michael Paquier
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.

[HACKERS] Move allocation size overflow handling to MemoryContextAllocExtended()?

2016-10-04 Thread Andres Freund
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