pgsql: Make more effort to put a sentinel at the end of allocated memor

Поиск
Список
Период
Сортировка
От David Rowley
Тема pgsql: Make more effort to put a sentinel at the end of allocated memor
Дата
Msg-id E1oVm24-001nSY-L6@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Make more effort to put a sentinel at the end of allocated memory

Traditionally, in MEMORY_CONTEXT_CHECKING builds, we only ever marked a
sentinel byte just beyond the requested size if there happened to be
enough space on the chunk to do so.  For Slab and Generation context
types, we only rounded the size of the chunk up to the next maxalign
boundary, so it was often not that likely that those would ever have space
for the sentinel given that the majority of allocation requests are going
to be for sizes which are maxaligned.  For AllocSet, it was a little
different as smaller allocations are rounded up to the next power-of-2
value rather than the next maxalign boundary, so we're a bit more likely
to have space for the sentinel byte, especially when we get away from tiny
sized allocations such as 8 or 16 bytes.

Here we make more of an effort to allow space so that there is enough room
for the sentinel byte in more cases.  This makes it more likely that we'll
detect when buggy code accidentally writes beyond the end of any of its
memory allocations.

Each of the 3 MemoryContext types has been changed as follows:

The Slab allocator will now always set a sentinel byte.  Both the current
usages of this MemoryContext type happen to use chunk sizes which were on
the maxalign boundary, so these never used sentinel bytes previously.

For the Generation allocator, we now always ensure there's enough space in
the allocation for a sentinel byte.

For AllocSet, this commit makes an adjustment for allocation sizes which
are greater than allocChunkLimit.  We now ensure there is always space for
a sentinel byte.  We don't alter the sentinel behavior for request sizes
<= allocChunkLimit.  Making way for the sentinel byte for power-of-2
request sizes would require doubling up to the next power of 2.  Some
analysis done on the request sizes made during installcheck shows that a
fairly large portion of allocation requests are for power-of-2 sizes.  The
amount of additional memory for the sentinel there seems prohibitive, so
we do nothing for those here.

Author: David Rowley
Discussion: https://postgr.es/m/3478405.1661824539@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/0e480385ec59aa7f769366eb24462acc2b7a40d7

Modified Files
--------------
src/backend/utils/mmgr/aset.c       | 41 ++++++++++++++++++++++++-----------
src/backend/utils/mmgr/generation.c | 43 +++++++++++++++++++++----------------
src/backend/utils/mmgr/slab.c       | 37 ++++++++++++++++---------------
3 files changed, 74 insertions(+), 47 deletions(-)


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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: pgsql: Doc: Explain about Column List feature.
Следующее
От: Peter Eisentraut
Дата:
Сообщение: pgsql: Renumber confusing value for GUC_UNIT_BYTE