2200H

At a glance

A sequence allocation reached its configured limit while trying to obtain the next value. PostgreSQL 18.6’s sequence.c path reports source templates for both maximum and minimum limits. The endpoint value itself can be legal, and the numeric value uses the C PRId64 format macro, so the source spelling is nextval: reached maximum value of sequence "%s" (%" PRId64 ") (and the corresponding minimum form), not a literal (%s) placeholder. The limit is a sequence property, not a generic integer overflow.

Meaning

This condition means the nextval fetch loop cannot allocate the next value past a configured sequence minimum or maximum. In the ascending path, PostgreSQL checks the maximum boundary; in the descending path, it checks the minimum. At a boundary, rescnt > 0 stops the fetch loop so already fetched legal values can be returned; only when no result remains does the non-cycling branch raise 2200H. With CYCLE, the fixed source wraps to the opposite configured endpoint. This is sequence boundary policy, not a generic integer overflow.

Messages

The non-cycling ascending guard raises ERROR with primary source template nextval: reached maximum value of sequence "%s" (%" PRId64 "); the descending guard uses nextval: reached minimum value of sequence "%s" (%" PRId64 "). The endpoint itself is not inherently an error: if the fetch loop already has a legal result, it stops fetching before the error branch. PRId64 is a C format macro concatenated into the compiled numeric placeholder, so the displayed number is a runtime limit value. The cited branches have no separate DETAIL or HINT.

Diagnosis

Inspect the named sequence, increment, MINVALUE/MAXVALUE, CYCLE setting, and whether the call was nextval. Determine whether the endpoint is maximum or minimum, whether a legal endpoint or cached value was still available, and whether cycling deliberately wraps. CYCLE is a sequence policy, not a universal repair for generated identifiers: changing it can create values that collide with dependent keys or violate an application’s allocation contract. If cycling is not intended, choose a new range, alter the sequence, or rotate to a new sequence after checking dependent keys.

Response

Repair the sequence policy deliberately: adjust a safe limit, enable or disable CYCLE only after checking key semantics, or migrate allocation to a new sequence. Repeating the same nextval, casting its result, or treating this as an integer overflow cannot advance past a fixed endpoint.

When this branch raises ERROR, an explicit transaction must first be recovered with ROLLBACK or ROLLBACK TO SAVEPOINT for a savepoint established before the statement; in autocommit, retry only the corrected action after the failed statement completes. See the transaction and retry guide for this boundary rule.

Versions

The locked catalogue records this condition from 10.0; fixed source coverage is PostgreSQL 18.6.

Related

22003, 22000

Sources

Fixed source: src/backend/commands/sequence.c#L731-769. The structured evidence record retains both limit messages and scope boundaries. The fixed source confirms the ascending and descending guards, CYCLE wrap, and C PRId64 format macro; the exact sequence name and limit are runtime values. Source presence begins at 10.0 in the locked catalogue, without asserting the precise implementation introduction commit.

Source evidence

Evidence belongs to the frozen source and runtime versions listed here. It is not a runtime verification of the selected manual version.

• src/backend/utils/errcodes.txt · REL_18_6 ·
  724edf9bde9d356724ad384a2e196edc3c9f80f7
• raw/calls/REL_18_6.jsonl · ·
• src/backend/commands/sequence.c · REL_18_6 ·
  724edf9bde9d356724ad384a2e196edc3c9f80f7

Message templates

nextval: reached maximum value of sequence "%s" (%" PRId64 ")

nextval: reached minimum value of sequence "%s" (%" PRId64 ")

Reproduction & repair cases

No reproduction case is attached to this condition.

Recorded runtime evidence

No runtime observation is attached to this entry.