diff options
| author | Tom Lane | 2016-03-12 21:05:10 +0000 |
|---|---|---|
| committer | Tom Lane | 2016-03-12 21:05:29 +0000 |
| commit | 23a27b039d94ba359286694831eafe03cd970eef (patch) | |
| tree | 4b1d6acb2fe4ae5c1275292adb3f027f2e052ea8 /src/include/utils | |
| parent | e01157500f26342bf4f067a4eb1e45ab9a3cd410 (diff) | |
Widen query numbers-of-tuples-processed counters to uint64.
This patch widens SPI_processed, EState's es_processed field, PortalData's
portalPos field, FuncCallContext's call_cntr and max_calls fields,
ExecutorRun's count argument, PortalRunFetch's result, and the max number
of rows in a SPITupleTable to uint64, and deals with (I hope) all the
ensuing fallout. Some of these values were declared uint32 before, and
others "long".
I also removed PortalData's posOverflow field, since that logic seems
pretty useless given that portalPos is now always 64 bits.
The user-visible results are that command tags for SELECT etc will
correctly report tuple counts larger than 4G, as will plpgsql's GET
GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples
than that are still not exactly the norm, but they're becoming more
common.
Most values associated with FETCH/MOVE distances, such as PortalRun's count
argument and the count argument of most SPI functions that have one, remain
declared as "long". It's not clear whether it would be worth promoting
those to int64; but it would definitely be a large dollop of additional
API churn on top of this, and it would only help 32-bit platforms which
seem relatively less likely to see any benefit.
Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
Diffstat (limited to 'src/include/utils')
| -rw-r--r-- | src/include/utils/builtins.h | 1 | ||||
| -rw-r--r-- | src/include/utils/portal.h | 11 |
2 files changed, 6 insertions, 6 deletions
diff --git a/src/include/utils/builtins.h b/src/include/utils/builtins.h index 115f8afb45b..59a00bbcbcf 100644 --- a/src/include/utils/builtins.h +++ b/src/include/utils/builtins.h @@ -292,6 +292,7 @@ extern void pg_ltoa(int32 l, char *a); extern void pg_lltoa(int64 ll, char *a); extern char *pg_ltostr_zeropad(char *str, int32 value, int32 minwidth); extern char *pg_ltostr(char *str, int32 value); +extern uint64 pg_strtouint64(const char *str, char **endptr, int base); /* * Per-opclass comparison functions for new btrees. These are diff --git a/src/include/utils/portal.h b/src/include/utils/portal.h index 4236215b796..7250c9c1bb3 100644 --- a/src/include/utils/portal.h +++ b/src/include/utils/portal.h @@ -166,15 +166,14 @@ typedef struct PortalData * atStart, atEnd and portalPos indicate the current cursor position. * portalPos is zero before the first row, N after fetching N'th row of * query. After we run off the end, portalPos = # of rows in query, and - * atEnd is true. If portalPos overflows, set posOverflow (this causes us - * to stop relying on its value for navigation). Note that atStart - * implies portalPos == 0, but not the reverse (portalPos could have - * overflowed). + * atEnd is true. Note that atStart implies portalPos == 0, but not the + * reverse: we might have backed up only as far as the first row, not to + * the start. Also note that various code inspects atStart and atEnd, but + * only the portal movement routines should touch portalPos. */ bool atStart; bool atEnd; - bool posOverflow; - long portalPos; + uint64 portalPos; /* Presentation data, primarily used by the pg_cursors system view */ TimestampTz creation_time; /* time at which this portal was defined */ |
