aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2024-07-06 14:00:06 +1200
committerDavid Rowley <drowley@postgresql.org>2024-07-06 14:00:06 +1200
commit84a9d38006280f092b2b3f14841e4156c7a6e80d (patch)
tree8246bea0a2b973cd8f5042005a5676fe796d3c9e /src/backend/executor/nodeModifyTable.c
parent9c273679b36b2c7c9ae13889ec6a5a3892842a6b (diff)
downloadpostgresql-84a9d38006280f092b2b3f14841e4156c7a6e80d.tar.gz
postgresql-84a9d38006280f092b2b3f14841e4156c7a6e80d.zip
Fix incorrect sentinel byte logic in GenerationRealloc()
This only affects MEMORY_CONTEXT_CHECKING builds. This fixes an off-by-one issue in GenerationRealloc() where the fast-path code which tries to reuse the existing allocation if the existing chunk is >= the new requested size. The code there thought it was always ok to use the existing chunk, but when oldsize == size there isn't enough space to store the sentinel byte. If both sizes matched exactly set_sentinel() would overwrite the first byte beyond the chunk and then subsequent GenerationRealloc() calls could then fail the Assert(chunk->requested_size < oldsize) check which is trying to ensure the chunk is large enough to store the sentinel. The same issue does not exist in aset.c as the sentinel checking code only adds a sentinel byte if there's enough space in the chunk. Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/49275921-7b39-41af-5eb8-97b50ce3312e@gmail.com Backpatch-through: 16, where the problem was introduced by 0e480385e
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions