Re: [COMMITTERS] pgsql: Add new function dsa_allocate0.

Thomas Munro <thomas.munro@enterprisedb.com>

From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-02-18T23:27:59Z
Lists: pgsql-hackers

Attachments

On Sun, Feb 19, 2017 at 11:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> On Sat, Feb 18, 2017 at 5:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@gmail.com> writes:
>>>> I'm thinking we should change this to look more like the
>>>> MemoryContextAlloc interface.
>
>>> +1
>
>> Maybe something like the attached?  I didn't add DSA_ALLOC_HUGE
>> because there is currently no limit on allocation size (other than the
>> limit on total size which you can set with dsa_set_size_limit, but
>> that causes allocation failure, not a separate kind of error).  Should
>> there be a per-allocation size sanity check of 1GB like palloc?
>
> I think it's not a bad idea.  It could help catch faulty allocation
> requests (since I'd bet very few call sites actually intend to allocate
> gigabytes in one go), and as Robert says, there is substantial value in
> the semantics being as much like palloc() as possible.  People are
> likely to assume that even if it isn't true.

Agreed.  Here's a patch like that.

-- 
Thomas Munro
http://www.enterprisedb.com

Commits

  1. Make dsa_allocate interface more like MemoryContextAlloc.

  2. Add new function dsa_allocate0.