On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: @@ -590,7 +622,14 @@ _bt_buildadd(BTWriteState *wstate, BTPageState *state, IndexTuple itup) if (last_off == P_HIKEY) { Assert(state->btps_minkey == NULL); - state->btps_minkey = CopyIndexTuple(itup); + /* + * Truncate the tuple that we're going to insert + * into the parent page as a downlink + */
+ if (indnkeyatts != indnatts && P_ISLEAF(pageop)) + state->btps_minkey = index_truncate_tuple(wstate->index, itup); + else + state->btps_minkey = CopyIndexTuple(itup); It seems that above code always ensure that for leaf pages, high key is a truncated tuple. What is less clear is if that is true, why you need to re-ensure it again for the old page in below code: @@ -510,6 +513,8 @@ _bt_buildadd(BTWriteState *wstate, BTPageState *state, IndexTuple itup) { .. + if (indnkeyatts != indnatts && P_ISLEAF(opageop)) + { + /* + * It's essential to truncate High key here. + * The purpose is not just to save more space on this particular page, + * but to keep whole b-tree structure consistent. Subsequent insertions + * assume that hikey is already truncated, and so they should not + * worry about it, when copying the high key into the parent page + * as a downlink. + * NOTE It is not crutial for reliability in present, + * but maybe it will be that in the future. + */ + keytup = index_truncate_tuple(wstate->index, oitup); + + /* delete "wrong" high key, insert keytup as P_HIKEY. */ + PageIndexTupleDelete(opage, P_HIKEY); + + if (!_bt_pgaddtup(opage, IndexTupleSize(keytup), keytup, P_HIKEY)) + elog(ERROR, "failed to rewrite compressed item in index \"%s\"", + RelationGetRelationName(wstate->index)); + } + .. .. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers