On Sun, Feb 19, 2017 at 12:27 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> 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.
Oops, that had a typo in a comment. Here's a better one.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers