Re: Some memory allocations in gin fastupdate code are a bit brain dead - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Some memory allocations in gin fastupdate code are a bit brain dead
Date
Msg-id 10262.1545237846@sss.pgh.pa.us
Whole thread Raw
In response to Re: Some memory allocations in gin fastupdate code are a bit brain dead  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Some memory allocations in gin fastupdate code are a bit brain dead  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> On Wed, 19 Dec 2018 at 04:24, Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Remove Deprecated Exclusive Backup Mode
Next
From: Tom Lane
Date:
Subject: Re: single user mode -P option is ignored