Re: Some memory allocations in gin fastupdate code are a bit brain dead

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On Wed, 19 Dec 2018 at 04:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Also, do we need to worry about integer overflow?

> Good point. I didn't think of it before, but the previous code would
> have ensured that we got an ERROR before any overflow could have
> occurred as the repalloc() would fail once the allocation request went
> beyond MaxAllocSize. However, I think an overflow is sufficiently
> unlikely that we don't need to do any batching, but we should keep it
> an error and not a crash.

Agreed.

> I propose the attached. If we hit the overflow case, we'll still
> attempt the repalloc(), but it'll fail, just as it would have before,
> just without the needless calls.

I don't think this is quite bulletproof against overflow, especially
in view of the rather careless mixing of int32 and uint32 variables
that exists here. The easiest way to make it bulletproof is to add
an explicit test, so I did that and pushed it.

regards, tom lane