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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Move allocation size overflow handling to MemoryContextAllocExtended()?
Date: 2016-10-05 01:40:29
Message-ID: 960.1475631629@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> 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 is a uint64
>> for example.

> Well, that duplicates the check and error message everywhere.

It seems like you're on the edge of reinventing calloc(), which is not an
API that anybody especially likes. The problem with trying to centralize
overflow handling is that there are too many different cases. calloc()
handles exactly one case, where the request is to be a product of exactly
two inputs that are individually not capable of overflowing. As best I
can follow what you've got in mind here, it would be equally likely to
cover only a subset of cases.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-10-05 01:50:02 Re: Declarative partitioning - another take
Previous Message Michael Paquier 2016-10-05 01:21:38 Re: Is the last 9.1 release planned?