Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.
От | Thomas Munro |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0. |
Дата | |
Msg-id | CAEepm=1OC3uphzWoY4vTDO07TF3W3ms0VgxbtEZ0vq5_LEFM8w@mail.gmail.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.
|
Список | pgsql-hackers |
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. Let's have DSA_ALLOC_HUGE, >> DSA_ALLOC_NO_OOM, and DSA_ALLOC_ZERO, just like the corresponding >> MCXT_* flags, and a function dsa_allocate_extended() that takes a >> flags argument. Then, dsa_allocate(x,y) can be a macro for >> dsa_allocate_extended(x,y,0) and dsa_allocate0(x,y) can be a macro for >> dsa_allocate_extended(x,y,DSA_ALLOC_ZERO). What this goof on my (and >> Dilip's) part illustrates to me is that having this interface behave >> significantly differently from the MemoryContextAlloc interface is >> going to cause mistakes. > > +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? -- 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 по дате отправления: