Re: [GENERAL] Insert result does not match record count

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Natalie Wenz <nataliewenz(at)ebureau(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] Insert result does not match record count
Date: 2014-02-02 16:12:08
Message-ID: 8046.1391357528@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> writes:
> Without re-doing the work, my IRC logs show that I was bothered by this
> in src/backend/tcop/postgres.c:

> max_rows = pq_getmsgint(&input_message, 4);

> I needed to change max_rows to int64 which meant I had to change
> pq_getmsgint to pq_getmsgint64 which made me a little worried.

As well you should be, because we are *not* doing that. That would be
a guaranteed-incompatible protocol change. Fortunately, I don't see
any functional need for widening the row-limit field in execute messages;
how likely is it that someone wants to fetch exactly 3 billion rows?
The practical use-cases for nonzero row limits generally involve fetching
a bufferload worth of data at a time, so that the restriction to getting
no more than INT_MAX rows at once is several orders of magnitude away
from being a problem.

The same goes for internal uses of row limits, which makes it
questionable whether it's worth changing the width of ExecutorRun's
count parameter, which is what I assume you were on about here. But
in any case, if we did that we'd not try to reflect it as far as here,
because the message format specs can't change.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gavin Flower 2014-02-02 16:28:19 Re: Transparent exchange BDE from Oracle to PostgreSQL
Previous Message Edson Richter 2014-02-02 12:18:39 Re: Transparent exchange BDE from Oracle to PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-02-02 16:13:54 Re: [COMMITTERS] pgsql: Include planning time in EXPLAIN ANALYZE output.
Previous Message Tom Lane 2014-02-02 15:59:02 Re: narwhal and PGDLLIMPORT