Improving overflow checks when adding tuple to PGresult Re: [GENERAL] Retrieving query results

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Igor Korot <ikorot01(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Improving overflow checks when adding tuple to PGresult Re: [GENERAL] Retrieving query results
Date: 2017-08-29 01:30:55
Message-ID: CAB7nPqTnA3No2_B6x-QXPLHga1HatPqmXd03Xub+rPpshpmyMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Mon, Aug 28, 2017 at 3:05 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> Attached are two patches:
> 1) 0001 refactors the code around pqAddTuple to be able to handle
> error messages and assign them in PQsetvalue particularly.
> 2) 0002 adds sanity checks in pqAddTuple for overflows, maximizing the
> size of what is allocated to INT_MAX but now more.
>
> pqRowProcessor() still has errmsgp, but it is never used on HEAD. At
> least with this set of patches it comes to be useful. We could rework
> check_field_number() to use as well an error message string, but I
> have left that out to keep things simple. Not sure if any complication
> is worth compared to just copying the error message in case of an
> unmatching column number.

As this change requires I think an extra lookup, I am moving the
discussion to -hackers with a proper subject and the set of patches
attached (and the test program). This patch is registered in the next
commit fest.
--
Michael

Attachment Content-Type Size
0001-Refactor-error-message-handling-in-pqAddTuple.patch application/octet-stream 4.9 KB
0002-Improve-overflow-checks-of-pqAddTuple-in-libpq.patch application/octet-stream 2.1 KB
pg_copy_res.c text/x-csrc 1.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-08-29 01:31:58 Re: Protect syscache from bloating with negative cache entries
Previous Message Masahiko Sawada 2017-08-29 01:27:50 Re: pgbench: Skipping the creating primary keys after initialization