Initialize padding bytes in btree_gist varbit support.

The code expands a varbit gist leaf key to a node key by copying the bit
data twice in a varlen datum, as both the lower and upper key. The lower key
was expanded to INTALIGN size, but the padding bytes were not initialized.
That's a problem because when the lower/upper keys are compared, the padding
bytes are used compared too, when the values are otherwise equal. That could
lead to incorrect query results.

REINDEX is advised for any btree_gist indexes on bit or bit varying data
type, to fix any garbage padding bytes on disk.

Per Valgrind, reported by Andres Freund. Backpatch to all supported
versions.

1 files changed, 8 insertions, 4 deletions

diff --git a/contrib/btree_gist/btree_bit.c b/contrib/btree_gist/btree_bit.c
index 8675d2488de..6cf417677e9 100644
--- a/contrib/btree_gist/btree_bit.c
+++ b/contrib/btree_gist/btree_bit.c
@@ -81,10 +81,14 @@ static bytea *
 gbt_bit_xfrm(bytea *leaf)
 {
 	bytea	   *out = leaf;
-	int			s = INTALIGN(VARBITBYTES(leaf) + VARHDRSZ);
-
-	out = palloc(s);
-	SET_VARSIZE(out, s);
+	int			sz = VARBITBYTES(leaf) + VARHDRSZ;
+	int			padded_sz = INTALIGN(sz);
+
+	out = (bytea *) palloc(padded_sz);
+	/* initialize the padding bytes to zero */
+	while (sz < padded_sz)
+		((char *) out)[sz++] = 0;
+	SET_VARSIZE(out, padded_sz);
 	memcpy((void *) VARDATA(out), (void *) VARBITS(leaf), VARBITBYTES(leaf));
 	return out;
 }