]> granicus.if.org Git - postgresql/commit
In PageIndexTupleDelete, don't assume stored item lengths are MAXALIGNed.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 9 Sep 2016 16:20:58 +0000 (12:20 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 9 Sep 2016 16:21:09 +0000 (12:21 -0400)
commit984d0a14e8d0141a68da5bd56ce6821042298904
tree4c135cd4cf126c3a018a856f02d07b35a835a0b5
parente0013deb5983303d945aacd56909ac4ce227fde1
In PageIndexTupleDelete, don't assume stored item lengths are MAXALIGNed.

PageAddItem stores the item length as-is.  It MAXALIGN's the amount of
space actually allocated for each tuple, but not the stored length.
PageRepairFragmentation, PageIndexMultiDelete, and PageIndexDeleteNoCompact
are all on board with this and MAXALIGN item lengths after fetching them.
But PageIndexTupleDelete expects the stored length to be a MAXALIGN
multiple already.  This accidentally works for existing index AMs because
they all maxalign their tuple sizes internally; but we don't do that for
heap tuples, and it shouldn't be a requirement for index tuples either.

So, sync PageIndexTupleDelete with the rest of bufpage.c by having it
maxalign the item size after fetching.

Also add a check that pd_special is maxaligned, to ensure that the test
"(offset + size) > phdr->pd_special" is still doing the right thing.
(If offset and pd_special are aligned, it doesn't matter whether size is.)
Again, this is in sync with the rest of the routines here, except for
PageAddItem which doesn't test because it doesn't actually do anything
for which pd_special alignment matters.

This shouldn't have any immediate functional impact; it just adds the
flexibility to use PageIndexTupleDelete on index tuples with non-aligned
lengths.

Discussion: <3814.1473366762@sss.pgh.pa.us>
src/backend/storage/page/bufpage.c