Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.
Date
Msg-id 28062.1487456862@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [HACKERS] pg_get_object_address() doesn't support composites
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion