Commit 4b42a899 authored by Peter Geoghegan's avatar Peter Geoghegan

Consistently truncate non-key suffix columns.

INCLUDE indexes failed to have their non-key attributes physically
truncated away in certain rare cases.  This led to physically larger
pivot tuples that contained useless non-key attribute values.  The
impact on users should be negligible, but this is still clearly a
regression (Postgres 11 supports INCLUDE indexes, and yet was not
affected).

The bug appeared in commit dd299df8, which introduced "true" suffix
truncation of key attributes.

Discussion: https://postgr.es/m/CAH2-Wz=E8pkV9ivRSFHtv812H5ckf8s1-yhx61_WrJbKccGcrQ@mail.gmail.com
Backpatch: 12-, where "true" suffix truncation was introduced.
parent 911e7020
......@@ -2205,7 +2205,8 @@ _bt_truncate(Relation rel, IndexTuple lastleft, IndexTuple firstright,
{
IndexTuple tidpivot;
pivot = index_truncate_tuple(itupdesc, firstright, keepnatts);
pivot = index_truncate_tuple(itupdesc, firstright,
Min(keepnatts, nkeyatts));
if (BTreeTupleIsPosting(pivot))
{
......@@ -2250,6 +2251,10 @@ _bt_truncate(Relation rel, IndexTuple lastleft, IndexTuple firstright,
/*
* No truncation was possible, since key attributes are all equal.
* It's necessary to add a heap TID attribute to the new pivot tuple.
*
* This path is only taken when rel is not an INCLUDE index. It
* avoids a second palloc0() by avoiding the index_truncate_tuple()
* call completely.
*/
Assert(natts == nkeyatts);
newsize = IndexTupleSize(firstright) + MAXALIGN(sizeof(ItemPointerData));
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment