rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix rare sharedtuplestore.c corruption. 

If the final chunk of an oversized tuple being written out to disk was
exactly 32760 bytes, it would be corrupted due to a fencepost bug.

Bug #17619.  Back-patch to 11 where the code arrived.

While testing that (see test module in archives), I (tmunro) noticed
that the per-participant page counter was not initialized to zero as it
should have been; that wasn't a live bug when it was written since DSM
memory was originally always zeroed, but since 14
min_dynamic_shared_memory might be configured and it supplies non-zeroed
memory, so that is also fixed here.

Author: Dmitry Astapov <dastapov@gmail.com>
Discussion: https://postgr.es/m/17619-0de62ceda812b8b5%40postgresql.org
This commit is contained in:
Thomas Munro 2023-01-26 14:50:07 +13:00
parent 9aeff092c0
commit ffcf6f4cfc
1 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/backend/utils/sort/sharedtuplestore.c
View File

@ -158,6 +158,7 @@ sts_initialize(SharedTuplestore *sts, int participants,
LWLockInitialize(&sts->participants[i].lock,
LWTRANCHE_SHARED_TUPLESTORE);
sts->participants[i].read_page = 0;
sts->participants[i].npages = 0;
sts->participants[i].writing = false;
}
@ -320,7 +321,7 @@ sts_puttuple(SharedTuplestoreAccessor *accessor, void *meta_data,
/* Do we have space? */
size = accessor->sts->meta_data_size + tuple->t_len;
if (accessor->write_pointer + size >= accessor->write_end)
if (accessor->write_pointer + size > accessor->write_end)
{
if (accessor->write_chunk == NULL)
{
@ -340,7 +341,7 @@ sts_puttuple(SharedTuplestoreAccessor *accessor, void *meta_data,
}
/* It may still not be enough in the case of a gigantic tuple. */
if (accessor->write_pointer + size >= accessor->write_end)
if (accessor->write_pointer + size > accessor->write_end)
{
size_t written;