Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.
От | Thomas Munro |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0. |
Дата | |
Msg-id | CAEepm=0ro7Wf8UOtCCGZsvSyL-18WpzKAoH-yUOuhEAY0z1ScA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0. (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: