Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.
От
Tom Lane
Тема
Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.
Дата
Msg-id
28062.1487456862@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0. Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0. Thomas Munro <thomas.munro@enterprisedb.com>
Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0. Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0. Thomas Munro <thomas.munro@enterprisedb.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. Robert Haas <robertmhaas@gmail.com>
Thomas Munro writes: > On Sat, Feb 18, 2017 at 5:41 AM, Tom Lane wrote: >> Robert Haas 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 по дате отправления
От: Jim Nasby
Дата:
От: Michael Paquier
Дата: