Re: BUG #19545: Integer truncation of `GinTuple.keylen` causes out-of-bounds read in parallel GIN index build

Ewan Young <kdbase(dot)hack(at)gmail(dot)com> writes:
> Agreed, that's clearly better. v3 (attached) uses Size for
> GinTuple.keylen (GinBuffer.keylen already was Size), and also for the
> local in _gin_build_tuple(), which was the int that truncated
> VARSIZE_ANY() in the first place.

Am I reading this correctly that you propose using Size for the
length of the key value (keylen) along with int for the length of the
whole tuple (tuplen)?

{
int tuplen; /* length of the whole tuple */
OffsetNumber attrnum; /* attnum of index key */
- uint16 keylen; /* bytes in data for key value */
+ Size keylen; /* bytes in data for key value */
int16 typlen; /* typlen for key */
bool typbyval; /* typbyval for key */
signed char category; /* category: normal or NULL? */

Please explain how that's sane.

I kind of agree with the upthread comment that we should just reject
key lengths exceeding BLCKSZ or so up-front, rather than fooling
around with these field widths. This patch widens GinTuple
noticeably, and will do so more if we also widen tuplen. Is that
free?

regards, tom lane