summaryrefslogtreecommitdiff
path: root/src/include/utils
diff options
context:
space:
mode:
authorTom Lane2016-03-12 21:05:10 +0000
committerTom Lane2016-03-12 21:05:29 +0000
commit23a27b039d94ba359286694831eafe03cd970eef (patch)
tree4b1d6acb2fe4ae5c1275292adb3f027f2e052ea8 /src/include/utils
parente01157500f26342bf4f067a4eb1e45ab9a3cd410 (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.h1
-rw-r--r--src/include/utils/portal.h11
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 */