On 1/6/17 2:15 PM, Daniel Verite wrote:
> I notice that there's a preexisting
> oddity in the fact that sequences created with a negative increment
> in current releases initialize the minval to -(2^63)+1 instead of -2^63,
> the actual lowest value for a bigint.
I think that had to do with that we had to play games to work around the
lack of proper int64 support, and various weird code has developed over
time because of that. I think we should fix it if we can.
The attached patch fixes the default minimum value to use the proper
int64 min value.
With this patch, when upgrading with pg_dump, descending sequences with
the previous default minimum value would be kept with that
now-not-default value. We could alternative adjust those sequences to
the new default value.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 5c0223292c1ad065d73294c99fae3da60407f001 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <pete...@gmx.net>
Date: Fri, 20 Jan 2017 19:58:56 -0500
Subject: [PATCH] Fix default minimum value for descending sequences
For some reason that is lost in history, a descending sequence would
default its minimum value to -2^63+1 (-PG_INT64_MAX) instead of
-2^63 (PG_INT64_MIN), even though explicitly specifying a minimum value
of -2^63 would work. Fix this inconsistency by using the full range by
default.
found by Daniel Verite <dan...@manitou-mail.org>
---
doc/src/sgml/ref/create_sequence.sgml | 2 +-
src/backend/commands/sequence.c | 4 ++--
src/bin/pg_dump/pg_dump.c | 4 ++--
src/include/pg_config_manual.h | 6 ------
4 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/doc/src/sgml/ref/create_sequence.sgml b/doc/src/sgml/ref/create_sequence.sgml
index 62ae379226..86ff018c4b 100644
--- a/doc/src/sgml/ref/create_sequence.sgml
+++ b/doc/src/sgml/ref/create_sequence.sgml
@@ -133,7 +133,7 @@ <title>Parameters</title>
the minimum value a sequence can generate. If this clause is not
supplied or <option>NO MINVALUE</option> is specified, then
defaults will be used. The defaults are 1 and
- -2<superscript>63</>-1 for ascending and descending sequences,
+ -2<superscript>63</> for ascending and descending sequences,
respectively.
</para>
</listitem>
diff --git a/src/backend/commands/sequence.c b/src/backend/commands/sequence.c
index 2de46c270e..bafa95ce8f 100644
--- a/src/backend/commands/sequence.c
+++ b/src/backend/commands/sequence.c
@@ -1352,7 +1352,7 @@ init_params(ParseState *pstate, List *options, bool isInit,
else if (isInit || max_value != NULL)
{
if (seqform->seqincrement > 0)
- seqform->seqmax = SEQ_MAXVALUE; /* ascending seq */
+ seqform->seqmax = PG_INT64_MAX; /* ascending seq */
else
seqform->seqmax = -1; /* descending seq */
seqdataform->log_cnt = 0;
@@ -1369,7 +1369,7 @@ init_params(ParseState *pstate, List *options, bool isInit,
if (seqform->seqincrement > 0)
seqform->seqmin = 1; /* ascending seq */
else
- seqform->seqmin = SEQ_MINVALUE; /* descending seq */
+ seqform->seqmin = PG_INT64_MIN; /* descending seq */
seqdataform->log_cnt = 0;
}
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 0bb363957a..3a698afac5 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -15894,8 +15894,8 @@ dumpSequence(Archive *fout, TableInfo *tbinfo)
/* Make sure we are in proper schema */
selectSourceSchema(fout, tbinfo->dobj.namespace->dobj.name);
- snprintf(bufm, sizeof(bufm), INT64_FORMAT, SEQ_MINVALUE);
- snprintf(bufx, sizeof(bufx), INT64_FORMAT, SEQ_MAXVALUE);
+ snprintf(bufm, sizeof(bufm), INT64_FORMAT, PG_INT64_MIN);
+ snprintf(bufx, sizeof(bufx), INT64_FORMAT, PG_INT64_MAX);
if (fout->remoteVersion >= 100000)
{
diff --git a/src/include/pg_config_manual.h b/src/include/pg_config_manual.h
index c07907145a..f3b35297d1 100644
--- a/src/include/pg_config_manual.h
+++ b/src/include/pg_config_manual.h
@@ -51,12 +51,6 @@
#define PARTITION_MAX_KEYS 32
/*
- * Set the upper and lower bounds of sequence values.
- */
-#define SEQ_MAXVALUE PG_INT64_MAX
-#define SEQ_MINVALUE (-SEQ_MAXVALUE)
-
-/*
* When we don't have native spinlocks, we use semaphores to simulate them.
* Decreasing this value reduces consumption of OS resources; increasing it
* may improve performance, but supplying a real spinlock implementation is
--
2.11.0
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
