2003-03-20 08:02:11 +01:00
|
|
|
<!--
|
2010-09-20 22:08:53 +02:00
|
|
|
doc/src/sgml/ref/alter_sequence.sgml
|
2003-03-20 08:02:11 +01:00
|
|
|
PostgreSQL documentation
|
|
|
|
-->
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refentry id="sql-altersequence">
|
2014-02-24 03:25:35 +01:00
|
|
|
<indexterm zone="sql-altersequence">
|
|
|
|
<primary>ALTER SEQUENCE</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2003-03-20 08:02:11 +01:00
|
|
|
<refmeta>
|
2010-04-03 09:23:02 +02:00
|
|
|
<refentrytitle>ALTER SEQUENCE</refentrytitle>
|
2008-11-14 11:22:48 +01:00
|
|
|
<manvolnum>7</manvolnum>
|
2003-03-20 08:02:11 +01:00
|
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
|
|
</refmeta>
|
2003-08-31 19:32:24 +02:00
|
|
|
|
2003-03-20 08:02:11 +01:00
|
|
|
<refnamediv>
|
2008-11-12 16:53:34 +01:00
|
|
|
<refname>ALTER SEQUENCE</refname>
|
2003-03-20 08:02:11 +01:00
|
|
|
<refpurpose>
|
2004-08-24 02:06:51 +02:00
|
|
|
change the definition of a sequence generator
|
2003-03-20 08:02:11 +01:00
|
|
|
</refpurpose>
|
2010-11-23 21:27:50 +01:00
|
|
|
</refnamediv>
|
2003-08-31 19:32:24 +02:00
|
|
|
|
2003-03-20 08:02:11 +01:00
|
|
|
<refsynopsisdiv>
|
2010-07-29 21:34:41 +02:00
|
|
|
<synopsis>
|
2017-02-10 21:12:32 +01:00
|
|
|
ALTER SEQUENCE [ IF EXISTS ] <replaceable class="parameter">name</replaceable>
|
|
|
|
[ AS <replaceable class="parameter">data_type</replaceable> ]
|
|
|
|
[ INCREMENT [ BY ] <replaceable class="parameter">increment</replaceable> ]
|
2003-03-20 08:02:11 +01:00
|
|
|
[ MINVALUE <replaceable class="parameter">minvalue</replaceable> | NO MINVALUE ] [ MAXVALUE <replaceable class="parameter">maxvalue</replaceable> | NO MAXVALUE ]
|
2008-05-17 03:20:39 +02:00
|
|
|
[ START [ WITH ] <replaceable class="parameter">start</replaceable> ]
|
|
|
|
[ RESTART [ [ WITH ] <replaceable class="parameter">restart</replaceable> ] ]
|
|
|
|
[ CACHE <replaceable class="parameter">cache</replaceable> ] [ [ NO ] CYCLE ]
|
2012-06-22 00:06:14 +02:00
|
|
|
[ OWNED BY { <replaceable class="parameter">table_name</replaceable>.<replaceable class="parameter">column_name</replaceable> | NONE } ]
|
2022-04-07 16:13:23 +02:00
|
|
|
ALTER SEQUENCE [ IF EXISTS ] <replaceable class="parameter">name</replaceable> SET { LOGGED | UNLOGGED }
|
2020-09-17 11:39:28 +02:00
|
|
|
ALTER SEQUENCE [ IF EXISTS ] <replaceable class="parameter">name</replaceable> OWNER TO { <replaceable class="parameter">new_owner</replaceable> | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
|
2012-01-24 00:25:04 +01:00
|
|
|
ALTER SEQUENCE [ IF EXISTS ] <replaceable class="parameter">name</replaceable> RENAME TO <replaceable class="parameter">new_name</replaceable>
|
|
|
|
ALTER SEQUENCE [ IF EXISTS ] <replaceable class="parameter">name</replaceable> SET SCHEMA <replaceable class="parameter">new_schema</replaceable>
|
2010-07-29 21:34:41 +02:00
|
|
|
</synopsis>
|
2003-09-09 20:28:53 +02:00
|
|
|
</refsynopsisdiv>
|
2003-03-20 08:02:11 +01:00
|
|
|
|
2003-09-09 20:28:53 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>ALTER SEQUENCE</command> changes the parameters of an existing
|
2005-08-01 18:11:14 +02:00
|
|
|
sequence generator. Any parameters not specifically set in the
|
|
|
|
<command>ALTER SEQUENCE</command> command retain their prior settings.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
You must own the sequence to use <command>ALTER SEQUENCE</command>.
|
|
|
|
To change a sequence's schema, you must also have <literal>CREATE</literal>
|
2005-08-01 18:11:14 +02:00
|
|
|
privilege on the new schema.
|
2008-06-15 03:25:54 +02:00
|
|
|
To alter the owner, you must also be a direct or indirect member of the new
|
|
|
|
owning role, and that role must have <literal>CREATE</literal> privilege on
|
|
|
|
the sequence's schema. (These restrictions enforce that altering the owner
|
|
|
|
doesn't do anything you couldn't do by dropping and recreating the sequence.
|
|
|
|
However, a superuser can alter ownership of any sequence anyway.)
|
2003-09-09 20:28:53 +02:00
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Parameters</title>
|
|
|
|
|
|
|
|
<para>
|
2003-03-20 08:02:11 +01:00
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
2003-09-22 02:16:58 +02:00
|
|
|
<term><replaceable class="parameter">name</replaceable></term>
|
2003-03-20 08:02:11 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2003-11-01 02:56:29 +01:00
|
|
|
The name (optionally schema-qualified) of a sequence to be altered.
|
2003-03-20 08:02:11 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><literal>IF EXISTS</literal></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Do not throw an error if the sequence does not exist. A notice is issued
|
|
|
|
in this case.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2017-02-10 21:12:32 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">data_type</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The optional
|
|
|
|
clause <literal>AS <replaceable class="parameter">data_type</replaceable></literal>
|
|
|
|
changes the data type of the sequence. Valid types are
|
2017-09-02 05:34:12 +02:00
|
|
|
<literal>smallint</literal>, <literal>integer</literal>,
|
2017-02-10 21:12:32 +01:00
|
|
|
and <literal>bigint</literal>.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-04-04 18:36:15 +02:00
|
|
|
Changing the data type automatically changes the minimum and maximum
|
|
|
|
values of the sequence if and only if the previous minimum and maximum
|
|
|
|
values were the minimum or maximum value of the old data type (in
|
|
|
|
other words, if the sequence had been created using <literal>NO
|
|
|
|
MINVALUE</literal> or <literal>NO MAXVALUE</literal>, implicitly or
|
|
|
|
explicitly). Otherwise, the minimum and maximum values are preserved,
|
|
|
|
unless new values are given as part of the same command. If the
|
|
|
|
minimum and maximum values do not fit into the new data type, an error
|
|
|
|
will be generated.
|
2017-02-10 21:12:32 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2003-03-20 08:02:11 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">increment</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2003-11-01 02:56:29 +01:00
|
|
|
The clause <literal>INCREMENT BY <replaceable
|
|
|
|
class="parameter">increment</replaceable></literal> is
|
|
|
|
optional. A positive value will make an ascending sequence, a
|
|
|
|
negative one a descending sequence. If unspecified, the old
|
|
|
|
increment value will be maintained.
|
2003-03-20 08:02:11 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">minvalue</replaceable></term>
|
2003-11-01 02:56:29 +01:00
|
|
|
<term><literal>NO MINVALUE</literal></term>
|
2003-03-20 08:02:11 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2003-11-01 02:56:29 +01:00
|
|
|
The optional clause <literal>MINVALUE <replaceable
|
|
|
|
class="parameter">minvalue</replaceable></literal> determines
|
|
|
|
the minimum value a sequence can generate. If <literal>NO
|
|
|
|
MINVALUE</literal> is specified, the defaults of 1 and
|
2017-02-10 21:12:32 +01:00
|
|
|
the minimum value of the data type for ascending and descending sequences,
|
2003-11-01 02:56:29 +01:00
|
|
|
respectively, will be used. If neither option is specified,
|
|
|
|
the current minimum value will be maintained.
|
2003-03-20 08:02:11 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">maxvalue</replaceable></term>
|
2003-11-01 02:56:29 +01:00
|
|
|
<term><literal>NO MAXVALUE</literal></term>
|
2003-03-20 08:02:11 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2003-11-01 02:56:29 +01:00
|
|
|
The optional clause <literal>MAXVALUE <replaceable
|
|
|
|
class="parameter">maxvalue</replaceable></literal> determines
|
|
|
|
the maximum value for the sequence. If <literal>NO
|
2017-01-25 15:28:38 +01:00
|
|
|
MAXVALUE</literal> is specified, the defaults of
|
2017-02-10 21:12:32 +01:00
|
|
|
the maximum value of the data type and -1 for ascending and descending
|
2003-11-01 02:56:29 +01:00
|
|
|
sequences, respectively, will be used. If neither option is
|
|
|
|
specified, the current maximum value will be maintained.
|
2003-03-20 08:02:11 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">start</replaceable></term>
|
2008-05-17 03:20:39 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The optional clause <literal>START WITH <replaceable
|
|
|
|
class="parameter">start</replaceable></literal> changes the
|
|
|
|
recorded start value of the sequence. This has no effect on the
|
2017-10-09 03:44:17 +02:00
|
|
|
<emphasis>current</emphasis> sequence value; it simply sets the value
|
|
|
|
that future <command>ALTER SEQUENCE RESTART</command> commands will use.
|
2008-05-17 03:20:39 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">restart</replaceable></term>
|
2003-03-20 08:02:11 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2008-05-17 01:36:05 +02:00
|
|
|
The optional clause <literal>RESTART [ WITH <replaceable
|
2008-05-17 03:20:39 +02:00
|
|
|
class="parameter">restart</replaceable> ]</literal> changes the
|
Make ALTER SEQUENCE, including RESTART, fully transactional.
Previously the changes to the "data" part of the sequence, i.e. the
one containing the current value, were not transactional, whereas the
definition, including minimum and maximum value were. That leads to
odd behaviour if a schema change is rolled back, with the potential
that out-of-bound sequence values can be returned.
To avoid the issue create a new relfilenode fork whenever ALTER
SEQUENCE is executed, similar to how TRUNCATE ... RESTART IDENTITY
already is already handled.
This commit also makes ALTER SEQUENCE RESTART transactional, as it
seems to be too confusing to have some forms of ALTER SEQUENCE behave
transactionally, some forms not. This way setval() and nextval() are
not transactional, but DDL is, which seems to make sense.
This commit also rolls back parts of the changes made in 3d092fe540
and f8dc1985f as they're now not needed anymore.
Author: Andres Freund
Discussion: https://postgr.es/m/20170522154227.nvafbsm62sjpbxvd@alap3.anarazel.de
Backpatch: Bug is in master/v10 only
2017-06-01 01:39:27 +02:00
|
|
|
current value of the sequence. This is similar to calling the
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>setval</function> function with <literal>is_called</literal> =
|
|
|
|
<literal>false</literal>: the specified value will be returned by the
|
|
|
|
<emphasis>next</emphasis> call of <function>nextval</function>.
|
|
|
|
Writing <literal>RESTART</literal> with no <replaceable
|
|
|
|
class="parameter">restart</replaceable> value is equivalent to supplying
|
|
|
|
the start value that was recorded by <command>CREATE SEQUENCE</command>
|
|
|
|
or last set by <command>ALTER SEQUENCE START WITH</command>.
|
2003-03-20 08:02:11 +01:00
|
|
|
</para>
|
2017-05-02 16:34:49 +02:00
|
|
|
|
|
|
|
<para>
|
Make ALTER SEQUENCE, including RESTART, fully transactional.
Previously the changes to the "data" part of the sequence, i.e. the
one containing the current value, were not transactional, whereas the
definition, including minimum and maximum value were. That leads to
odd behaviour if a schema change is rolled back, with the potential
that out-of-bound sequence values can be returned.
To avoid the issue create a new relfilenode fork whenever ALTER
SEQUENCE is executed, similar to how TRUNCATE ... RESTART IDENTITY
already is already handled.
This commit also makes ALTER SEQUENCE RESTART transactional, as it
seems to be too confusing to have some forms of ALTER SEQUENCE behave
transactionally, some forms not. This way setval() and nextval() are
not transactional, but DDL is, which seems to make sense.
This commit also rolls back parts of the changes made in 3d092fe540
and f8dc1985f as they're now not needed anymore.
Author: Andres Freund
Discussion: https://postgr.es/m/20170522154227.nvafbsm62sjpbxvd@alap3.anarazel.de
Backpatch: Bug is in master/v10 only
2017-06-01 01:39:27 +02:00
|
|
|
In contrast to a <function>setval</function> call,
|
|
|
|
a <literal>RESTART</literal> operation on a sequence is transactional
|
|
|
|
and blocks concurrent transactions from obtaining numbers from the
|
|
|
|
same sequence. If that's not the desired mode of
|
2017-10-09 03:44:17 +02:00
|
|
|
operation, <function>setval</function> should be used.
|
2017-05-02 16:34:49 +02:00
|
|
|
</para>
|
2003-03-20 08:02:11 +01:00
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">cache</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2003-11-01 02:56:29 +01:00
|
|
|
The clause <literal>CACHE <replaceable
|
|
|
|
class="parameter">cache</replaceable></literal> enables
|
|
|
|
sequence numbers to be preallocated and stored in memory for
|
|
|
|
faster access. The minimum value is 1 (only one value can be
|
|
|
|
generated at a time, i.e., no cache). If unspecified, the old
|
|
|
|
cache value will be maintained.
|
2003-03-20 08:02:11 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2005-09-13 17:24:57 +02:00
|
|
|
<term><literal>CYCLE</literal></term>
|
2003-03-20 08:02:11 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
Update reference documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 00:26:05 +01:00
|
|
|
The optional <literal>CYCLE</literal> key word can be used to enable
|
2003-11-01 02:56:29 +01:00
|
|
|
the sequence to wrap around when the
|
|
|
|
<replaceable class="parameter">maxvalue</replaceable> or
|
|
|
|
<replaceable class="parameter">minvalue</replaceable> has been
|
|
|
|
reached by
|
|
|
|
an ascending or descending sequence respectively. If the limit is
|
|
|
|
reached, the next number generated will be the
|
|
|
|
<replaceable class="parameter">minvalue</replaceable> or
|
|
|
|
<replaceable class="parameter">maxvalue</replaceable>,
|
|
|
|
respectively.
|
2003-03-20 08:02:11 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2003-11-01 02:56:29 +01:00
|
|
|
<varlistentry>
|
2005-09-13 17:24:57 +02:00
|
|
|
<term><literal>NO CYCLE</literal></term>
|
2003-11-01 02:56:29 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
If the optional <literal>NO CYCLE</literal> key word is
|
|
|
|
specified, any calls to <function>nextval</function> after the
|
|
|
|
sequence has reached its maximum value will return an error.
|
|
|
|
If neither <literal>CYCLE</literal> or <literal>NO
|
2005-10-15 22:12:33 +02:00
|
|
|
CYCLE</literal> are specified, the old cycle behavior will be
|
2003-11-01 02:56:29 +01:00
|
|
|
maintained.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2005-08-01 18:11:14 +02:00
|
|
|
|
2022-04-07 16:13:23 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><literal>SET { LOGGED | UNLOGGED }</literal></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
This form changes the sequence from unlogged to logged or vice-versa
|
|
|
|
(see <xref linkend="sql-createsequence"/>). It cannot be applied to a
|
|
|
|
temporary sequence.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2006-08-21 02:57:26 +02:00
|
|
|
<varlistentry>
|
2012-06-22 00:06:14 +02:00
|
|
|
<term><literal>OWNED BY</literal> <replaceable class="parameter">table_name</replaceable>.<replaceable class="parameter">column_name</replaceable></term>
|
2006-08-21 02:57:26 +02:00
|
|
|
<term><literal>OWNED BY NONE</literal></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The <literal>OWNED BY</literal> option causes the sequence to be
|
|
|
|
associated with a specific table column, such that if that column
|
|
|
|
(or its whole table) is dropped, the sequence will be automatically
|
|
|
|
dropped as well. If specified, this association replaces any
|
|
|
|
previously specified association for the sequence. The specified
|
|
|
|
table must have the same owner and be in the same schema as the
|
|
|
|
sequence.
|
|
|
|
Specifying <literal>OWNED BY NONE</literal> removes any existing
|
2017-10-09 03:44:17 +02:00
|
|
|
association, making the sequence <quote>free-standing</quote>.
|
2006-08-21 02:57:26 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2008-06-15 03:25:54 +02:00
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">new_owner</replaceable></term>
|
2008-06-15 03:25:54 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The user name of the new owner of the sequence.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2007-07-03 03:30:37 +02:00
|
|
|
<varlistentry>
|
2007-10-03 18:48:43 +02:00
|
|
|
<term><replaceable class="parameter">new_name</replaceable></term>
|
2007-07-03 03:30:37 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2007-10-03 18:48:43 +02:00
|
|
|
The new name for the sequence.
|
2007-07-03 03:30:37 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2007-10-03 18:48:43 +02:00
|
|
|
<term><replaceable class="parameter">new_schema</replaceable></term>
|
2007-07-03 03:30:37 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2007-10-03 18:48:43 +02:00
|
|
|
The new schema for the sequence.
|
2007-07-03 03:30:37 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2003-03-20 08:02:11 +01:00
|
|
|
</variablelist>
|
|
|
|
</para>
|
2003-09-09 20:28:53 +02:00
|
|
|
</refsect1>
|
2003-03-20 08:02:11 +01:00
|
|
|
|
2003-09-09 20:28:53 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Notes</title>
|
|
|
|
|
2003-06-12 09:49:43 +02:00
|
|
|
<para>
|
2003-09-09 20:28:53 +02:00
|
|
|
<command>ALTER SEQUENCE</command> will not immediately affect
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>nextval</function> results in backends,
|
2003-09-09 20:28:53 +02:00
|
|
|
other than the current one, that have preallocated (cached) sequence
|
|
|
|
values. They will use up all cached values prior to noticing the changed
|
2006-08-21 02:57:26 +02:00
|
|
|
sequence generation parameters. The current backend will be affected
|
|
|
|
immediately.
|
2003-06-12 09:49:43 +02:00
|
|
|
</para>
|
2005-08-01 18:11:14 +02:00
|
|
|
|
2007-10-25 20:54:03 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<command>ALTER SEQUENCE</command> does not affect the <function>currval</function>
|
2007-10-25 20:54:03 +02:00
|
|
|
status for the sequence. (Before <productname>PostgreSQL</productname>
|
|
|
|
8.3, it sometimes did.)
|
|
|
|
</para>
|
|
|
|
|
Fix ALTER SEQUENCE locking
In 1753b1b027035029c2a2a1649065762fafbf63f3, the pg_sequence system
catalog was introduced. This made sequence metadata changes
transactional, while the actual sequence values are still behaving
nontransactionally. This requires some refinement in how ALTER
SEQUENCE, which operates on both, locks the sequence and the catalog.
The main problems were:
- Concurrent ALTER SEQUENCE causes "tuple concurrently updated" error,
caused by updates to pg_sequence catalog.
- Sequence WAL writes and catalog updates are not protected by same
lock, which could lead to inconsistent recovery order.
- nextval() disregarding uncommitted ALTER SEQUENCE changes.
To fix, nextval() and friends now lock the sequence using
RowExclusiveLock instead of AccessShareLock. ALTER SEQUENCE locks the
sequence using ShareRowExclusiveLock. This means that nextval() and
ALTER SEQUENCE block each other, and ALTER SEQUENCE on the same sequence
blocks itself. (This was already the case previously for the OWNER TO,
RENAME, and SET SCHEMA variants.) Also, rearrange some code so that the
entire AlterSequence is protected by the lock on the sequence.
As an exception, use reduced locking for ALTER SEQUENCE ... RESTART.
Since that is basically a setval(), it does not require the full locking
of other ALTER SEQUENCE actions. So check whether we are only running a
RESTART and run with less locking if so.
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
Reported-by: Jason Petersen <jason@citusdata.com>
Reported-by: Andres Freund <andres@anarazel.de>
2017-05-10 05:35:31 +02:00
|
|
|
<para>
|
|
|
|
<command>ALTER SEQUENCE</command> blocks
|
|
|
|
concurrent <function>nextval</function>, <function>currval</function>,
|
Make ALTER SEQUENCE, including RESTART, fully transactional.
Previously the changes to the "data" part of the sequence, i.e. the
one containing the current value, were not transactional, whereas the
definition, including minimum and maximum value were. That leads to
odd behaviour if a schema change is rolled back, with the potential
that out-of-bound sequence values can be returned.
To avoid the issue create a new relfilenode fork whenever ALTER
SEQUENCE is executed, similar to how TRUNCATE ... RESTART IDENTITY
already is already handled.
This commit also makes ALTER SEQUENCE RESTART transactional, as it
seems to be too confusing to have some forms of ALTER SEQUENCE behave
transactionally, some forms not. This way setval() and nextval() are
not transactional, but DDL is, which seems to make sense.
This commit also rolls back parts of the changes made in 3d092fe540
and f8dc1985f as they're now not needed anymore.
Author: Andres Freund
Discussion: https://postgr.es/m/20170522154227.nvafbsm62sjpbxvd@alap3.anarazel.de
Backpatch: Bug is in master/v10 only
2017-06-01 01:39:27 +02:00
|
|
|
<function>lastval</function>, and <command>setval</command> calls.
|
Fix ALTER SEQUENCE locking
In 1753b1b027035029c2a2a1649065762fafbf63f3, the pg_sequence system
catalog was introduced. This made sequence metadata changes
transactional, while the actual sequence values are still behaving
nontransactionally. This requires some refinement in how ALTER
SEQUENCE, which operates on both, locks the sequence and the catalog.
The main problems were:
- Concurrent ALTER SEQUENCE causes "tuple concurrently updated" error,
caused by updates to pg_sequence catalog.
- Sequence WAL writes and catalog updates are not protected by same
lock, which could lead to inconsistent recovery order.
- nextval() disregarding uncommitted ALTER SEQUENCE changes.
To fix, nextval() and friends now lock the sequence using
RowExclusiveLock instead of AccessShareLock. ALTER SEQUENCE locks the
sequence using ShareRowExclusiveLock. This means that nextval() and
ALTER SEQUENCE block each other, and ALTER SEQUENCE on the same sequence
blocks itself. (This was already the case previously for the OWNER TO,
RENAME, and SET SCHEMA variants.) Also, rearrange some code so that the
entire AlterSequence is protected by the lock on the sequence.
As an exception, use reduced locking for ALTER SEQUENCE ... RESTART.
Since that is basically a setval(), it does not require the full locking
of other ALTER SEQUENCE actions. So check whether we are only running a
RESTART and run with less locking if so.
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
Reported-by: Jason Petersen <jason@citusdata.com>
Reported-by: Andres Freund <andres@anarazel.de>
2017-05-10 05:35:31 +02:00
|
|
|
</para>
|
|
|
|
|
2005-08-01 18:11:14 +02:00
|
|
|
<para>
|
2008-06-15 03:25:54 +02:00
|
|
|
For historical reasons, <command>ALTER TABLE</command> can be used with
|
|
|
|
sequences too; but the only variants of <command>ALTER TABLE</command>
|
|
|
|
that are allowed with sequences are equivalent to the forms shown above.
|
2005-08-01 18:11:14 +02:00
|
|
|
</para>
|
2003-03-20 08:02:11 +01:00
|
|
|
</refsect1>
|
|
|
|
|
2007-10-03 18:48:43 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Examples</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Restart a sequence called <literal>serial</literal>, at 105:
|
|
|
|
<programlisting>
|
|
|
|
ALTER SEQUENCE serial RESTART WITH 105;
|
2011-08-07 09:49:45 +02:00
|
|
|
</programlisting></para>
|
2007-10-03 18:48:43 +02:00
|
|
|
</refsect1>
|
2003-03-20 08:02:11 +01:00
|
|
|
|
2003-09-09 20:28:53 +02:00
|
|
|
<refsect1>
|
2004-11-27 22:27:08 +01:00
|
|
|
<title>Compatibility</title>
|
2003-03-20 08:02:11 +01:00
|
|
|
|
2004-11-27 22:27:08 +01:00
|
|
|
<para>
|
2005-11-01 22:09:51 +01:00
|
|
|
<command>ALTER SEQUENCE</command> conforms to the <acronym>SQL</acronym>
|
2017-10-09 03:44:17 +02:00
|
|
|
standard, except for the <literal>AS</literal>, <literal>START WITH</literal>,
|
|
|
|
<literal>OWNED BY</literal>, <literal>OWNER TO</literal>, <literal>RENAME TO</literal>, and
|
2007-10-03 18:48:43 +02:00
|
|
|
<literal>SET SCHEMA</literal> clauses, which are
|
|
|
|
<productname>PostgreSQL</productname> extensions.
|
2004-11-27 22:27:08 +01:00
|
|
|
</para>
|
2003-03-20 08:02:11 +01:00
|
|
|
</refsect1>
|
2006-08-21 02:57:26 +02:00
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>See Also</title>
|
|
|
|
|
|
|
|
<simplelist type="inline">
|
2017-11-23 15:39:47 +01:00
|
|
|
<member><xref linkend="sql-createsequence"/></member>
|
|
|
|
<member><xref linkend="sql-dropsequence"/></member>
|
2006-08-21 02:57:26 +02:00
|
|
|
</simplelist>
|
|
|
|
</refsect1>
|
|
|
|
|
2003-03-20 08:02:11 +01:00
|
|
|
</refentry>
|