Fix GiST index-only scan column alignment issue. An index-only scan filled its result slot from the HeapTuple an index AM returns in scan->xs_hitup by deforming it with the virtual slot's own tuple descriptor (during GiST and SP-GiST index-only scans). But index AMs form that heap tuple using their own descriptor, scan->xs_hitupdesc. The AM's descriptor may disagree with the IoS virtual slot's descriptor about each column's precise alignment, leading to "can't happen" errors in certain rare edge cases. Hard crashes were possible but much less likely.
To fix, deform the tuple with the descriptor it was formed with. This is simpler, and makes xs_hitup handling (used by GiST and SP-GiST) uniform with the nearby existing xs_itup handling (used by nbtree). In practice this issue was very unlikely to be hit (it was found during testing of a patch that will change the table AM API used during index scans). The only currently affected core opclass is GiST's range_ops. It was only possible for the datum to be accessed at an incorrectly aligned offset when reading the second or subsequent column from a multicolumn GiST index. This couldn't happen in the common case where the datum used an unaligned short varlena header. Moreover, an earlier column had to leave the range datum at an offset where the two alignments actually disagree (e.g., an odd-length varlena datum). Author: Peter Geoghegan <[email protected]> Reviewed-by: Tomas Vondra <[email protected]> Discussion: https://postgr.es/m/cah2-wzkgxa2sknebdw29rt1hccqbo_p03v3iqif2u9bjzlb...@mail.gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/959b7fa2cd603ec353aaef715993d0f0816febd2 Modified Files -------------- src/backend/executor/nodeIndexonlyscan.c | 113 ++++++++++++++++--------------- src/test/regress/expected/gist.out | 36 ++++++++++ src/test/regress/sql/gist.sql | 29 ++++++++ 3 files changed, 124 insertions(+), 54 deletions(-)
