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