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.  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
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.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] pg_get_object_address() doesn't support composites
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion