Re: [GENERAL] Retrieving query results
| От | Tom Lane |
|---|---|
| Тема | Re: [GENERAL] Retrieving query results |
| Дата | |
| Msg-id | 17247.1503616204@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [GENERAL] Retrieving query results (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: [GENERAL] Retrieving query results
|
| Список | pgsql-general |
Michael Paquier <michael.paquier@gmail.com> writes:
> On Thu, Aug 24, 2017 at 11:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I haven't tried it, but it sure looks like it would, if you don't hit
>> OOM first. pqAddTuple() isn't doing anything to guard against integer
>> overflow. The lack of reports implies that no one has ever tried to
>> retrieve even 1G rows, let alone more ...
> Yeah, looking at the code we would just need to check if ntups gets
> negative (well, equal to INT_MIN) after being incremented.
I think the real problem occurs where we realloc the array bigger.
tupArrSize needs to be kept to no more than INT_MAX --- and, ideally,
it should reach that value rather than dying on the iteration after
it reaches 2^30 (so that we support resultsets as large as we possibly
can). Without a range-check, it's not very clear what realloc will think
it's being asked for. Also, on 32-bit machines, we could overflow size_t
before tupArrSize even gets that big, so a test against
SIZE_MAX/sizeof(pointer) may be needed as well.
As long as we constrain tupArrSize to be within bounds, we don't
have to worry about overflow of ntups per se.
regards, tom lane
В списке pgsql-general по дате отправления: