From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Add new function dsa_allocate0. |
Date: | 2017-02-18 22:27:42 |
Message-ID: | 28062.1487456862@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Sat, Feb 18, 2017 at 5:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2017-02-18 23:27:59 | Re: [COMMITTERS] pgsql: Add new function dsa_allocate0. |
Previous Message | Thomas Munro | 2017-02-18 21:06:41 | Re: [COMMITTERS] pgsql: Add new function dsa_allocate0. |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-02-18 23:02:07 | Re: Provide list of subscriptions and publications in psql's completion |
Previous Message | Jim Nasby | 2017-02-18 22:26:34 | Re: pg_get_object_address() doesn't support composites |