]> granicus.if.org Git - postgresql/commit
Teach libpq to detect integer overflow in the row count of a PGresult.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 29 Aug 2017 19:18:01 +0000 (15:18 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 29 Aug 2017 19:18:01 +0000 (15:18 -0400)
commit1c53722ffd0088679cb548da2bce569b5c2f9732
tree51f74c17b974cd635b5e5d703da19ab329bd5e6b
parente19e12be48337e85d9f5d8a38c1a10e2d425ce1f
Teach libpq to detect integer overflow in the row count of a PGresult.

Adding more than 1 billion rows to a PGresult would overflow its ntups and
tupArrSize fields, leading to client crashes.  It'd be desirable to use
wider fields on 64-bit machines, but because all of libpq's external APIs
use plain "int" for row counters, that's going to be hard to accomplish
without an ABI break.  Given the lack of complaints so far, and the general
pain that would be involved in using such huge PGresults, let's settle for
just preventing the overflow and reporting a useful error message if it
does happen.  Also, for a couple more lines of code we can increase the
threshold of trouble from INT_MAX/2 to INT_MAX rows.

To do that, refactor pqAddTuple() to allow returning an error message that
replaces the default assumption that it failed because of out-of-memory.

Along the way, fix PQsetvalue() so that it reports all failures via
pqInternalNotice().  It already did so in the case of bad field number,
but neglected to report anything for other error causes.

Because of the potential for crashes, this seems like a back-patchable
bug fix, despite the lack of field reports.

Michael Paquier, per a complaint from Igor Korot.

Discussion: https://postgr.es/m/CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com
src/interfaces/libpq/fe-exec.c