Michael Paquier <michael.paquier@xxxxxxxxx> writes: > On Thu, Aug 24, 2017 at 11:56 PM, Tom Lane <tgl@xxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
