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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Some memory allocations in gin fastupdate code are a bit brain dead
Дата
Msg-id 10262.1545237846@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Some memory allocations in gin fastupdate code are a bit brain dead  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: Some memory allocations in gin fastupdate code are a bit brain dead  (David Rowley <david.rowley@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: Remove Deprecated Exclusive Backup Mode
Следующее
От: Tom Lane
Дата:
Сообщение: Re: single user mode -P option is ignored