From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
cc: Igor Korot <ikorot01@gmail.com>,
        pgsql-general <pgsql-general@postgresql.org>
Subject: Re: Retrieving query results
In-reply-to: 
 <CAB7nPqSE5voeA5LTDZ6PLkA4jNWuYB7nJJTaXRJBREH2LJE2Fg@mail.gmail.com>
References: 
 <CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com>
 <CAB7nPqTzPvrwDakXjogGCLZGfMpQO1AMWY3e3RMp7SsDGvdUSw@mail.gmail.com>
 <32584.1503579096@sss.pgh.pa.us>
 <CA+FnnTxaA2cuEQiMx4-XFwBX3mdFL5wRq_xcN_+chNM-HdQtYg@mail.gmail.com>
 <14978.1503586593@sss.pgh.pa.us>
 <CAB7nPqSE5voeA5LTDZ6PLkA4jNWuYB7nJJTaXRJBREH2LJE2Fg@mail.gmail.com>
Comments: In-reply-to Michael Paquier <michael.paquier@gmail.com>
	message dated "Fri, 25 Aug 2017 07:57:50 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17246.1503616204.1@sss.pgh.pa.us>
Date: Thu, 24 Aug 2017 19:10:04 -0400
Message-ID: <17247.1503616204@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org

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


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general