Date: Mon, 10 Jun 2024 18:10:49 -0700 (PDT)
From: Rich Shepard <rshepard@appl-ecosys.com>
To: pgsql-general@lists.postgresql.org
Subject: Re: Gaps in PK sequence numbers [RESOLVED]
In-Reply-To: <DB68A3C3-FCF6-4815-9C5C-A77310B66474@thebuild.com>
Message-ID: <f9ab3b2b-508-ddcf-f01c-3c805242ee3@appl-ecosys.com>
References: <35fd10ab-5f7f-7a57-9cc5-c03d81476d13@appl-ecosys.com> <DB68A3C3-FCF6-4815-9C5C-A77310B66474@thebuild.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://www.postgresql.org/message-id/f9ab3b2b-508-ddcf-f01c-3c805242ee3%40appl-ecosys.com>
Precedence: bulk

On Mon, 10 Jun 2024, Christophe Pettus wrote:

> Strictly speaking, the sequence underlying nextval() has no idea what
> primary keys are or are not in use. It's just a transaction-ignoring
> counter that increases with each nextval() call. The only reason that
> you'd get duplicate key errors in this case are:
>
> 1. The sequence was reset to a different, lower value.
> 2. Rows were inserted that didn't use the sequence to select a primary key.

Thanks, Christophe. Is there a way to reset the sequence to the maximum
number +1? I don't recall seeing this in the postgres docs but will look
again.

Regards,

Rich