Re: Expand palloc/pg_malloc API
От
Tom Lane
Тема
Re: Expand palloc/pg_malloc API
Дата
Msg-id
2524580.1663131186@sss.pgh.pa.us
Ответ на
Re: Expand palloc/pg_malloc API (Tom Lane)
Список
Дерево обсуждения
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 по дате отправления