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
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? |