Re: Expand palloc/pg_malloc API

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Expand palloc/pg_malloc API
Дата
Msg-id
2524580.1663131186@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Expand palloc/pg_malloc API Tom Lane <tgl@sss.pgh.pa.us>
Re: Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Tom Lane <tgl@sss.pgh.pa.us>
Re: Expand palloc/pg_malloc API "David G. Johnston" <david.g.johnston@gmail.com>
Re: Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Tom Lane <tgl@sss.pgh.pa.us>
Re: Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Tom Lane <tgl@sss.pgh.pa.us>
Re: Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Tom Lane <tgl@sss.pgh.pa.us>
Re: Expand palloc/pg_malloc API Tom Lane <tgl@sss.pgh.pa.us>
Re: Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Tom Lane <tgl@sss.pgh.pa.us>
Re: Expand palloc/pg_malloc API Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Expand palloc/pg_malloc API Tom Lane <tgl@sss.pgh.pa.us>
Re: Expand palloc/pg_malloc API Robert Haas <robertmhaas@gmail.com>
Re: Expand palloc/pg_malloc API Tom Lane <tgl@sss.pgh.pa.us>
I wrote:
> It kind of feels that the argument order should be pointer, oldsize, size.
> It feels even more strongly that people will get the ordering wrong,
> whichever we choose.  Is there a way to make that more bulletproof?

Actually ... an even-more-terrifyingly-plausible misuse is that the
supplied oldsize is different from the actual previous allocation.
We should try to check that.  In MEMORY_CONTEXT_CHECKING builds
it should be possible to assert that oldsize == requested_size.
We don't have that data if !MEMORY_CONTEXT_CHECKING, but we could
at least assert that oldsize <= allocated chunk size.

			regards, tom lane


В списке pgsql-hackers по дате отправления
От: John Naylor
Дата:
От: Michael Paquier
Дата:
FAQ