Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHsx2-00BOlS-3Y for pgsql-general@arkaria.postgresql.org; Thu, 13 Jun 2024 22:29:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sHswz-008vxH-UA for pgsql-general@arkaria.postgresql.org; Thu, 13 Jun 2024 22:29:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHswz-008vx8-JF for pgsql-general@lists.postgresql.org; Thu, 13 Jun 2024 22:29:46 +0000 Received: from mail-oo1-xc30.google.com ([2607:f8b0:4864:20::c30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sHswt-001Bja-NT for pgsql-general@lists.postgresql.org; Thu, 13 Jun 2024 22:29:45 +0000 Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-5b96a95c5e8so894255eaf.3 for ; Thu, 13 Jun 2024 15:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718317779; x=1718922579; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QSOGb+cBkRzaZ6IuXrR0uCfbRCHCgzhFS44xzQbcDfk=; b=BZihpwJb1RmVidkqCUxPdbadHfCD4Xr1QJsmTG7Moehk0ifsiXRc3KflR4wYagAs7r 8hvNu18yl7cbr66TBMqk/NwLZ8Pyhqc3nLhLib6Ps7cdA7lOd6dTV/p9jQp7kA+2L+gC 0L4NDrLvSHPtKP4dB2rX4XSsgekh+DXC01sN8v0yq411+kgoiPajDRRHBH0nH48U+Ycx 6NXmwg44di9vADq9ea8BwPWsbMshluRRJ8At/luhC9XgRBTiR855QvrbK+YB7BhnbaNS BbUiifhLs9/uGNqW8qk0Nze626xelm/mgBChYlg6gcaSy/+tMsEOds/4oTyH/mdwoqD5 UtoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718317779; x=1718922579; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QSOGb+cBkRzaZ6IuXrR0uCfbRCHCgzhFS44xzQbcDfk=; b=w0F2j0x/Kp0SJbGOuG8TELSft/XGsMRq0hRAYW3CKPq4Z0kbFhATEesmNP5lQ63nZK ZN6qERKh0neevP4S5H6C0DC+lD14k5FZ3JB9grPRcaLK9ZfCTukOw9jrczIR+7UmFvOQ NjrxPQK9W7cSex2URZoP+Bd4TGU5fxbps3X5Cl8mCD6BaEPGmCO3RpQo+Oa/GhupAPHT W6dp+lD1ain5mMgBB5C0174t1GIkRZcKFYDJTW7rea2CCoUB8TKl2VQEJhjLpRcSpLZI tGDSP7l4405vux0rKYgFh1DxkNQ1OYQF9Vk4uIWQ73aHW1HmloQxQXI//tiAsNJ7hLWK iapA== X-Gm-Message-State: AOJu0Yy+shWLNWF8dfp+DpuaQ6kp+cSbEosByxb/n+uBPNkvBNxOh7f+ xGsrcurx5sTU3O9MBROg6dWwM7CZN5avFc5u6C6xRTxzWi6SGXccOmcnjQ3Nny5wx1gqv/JXBVk 48a4JePmjM6+nKFu46sUbXcGtsUw= X-Google-Smtp-Source: AGHT+IGUF0NMoqQECb+OXHv5ga8dLahJgTYMjlC6pkK38sV04EKKpodgQdB7qMQuYLIH0O9uMyUd/9+UtDMdsimw2WI= X-Received: by 2002:a4a:d249:0:b0:5bd:ae80:865b with SMTP id 006d021491bc7-5bdae8086b1mr677255eaf.9.1718317779030; Thu, 13 Jun 2024 15:29:39 -0700 (PDT) MIME-Version: 1.0 References: <387fa6c2-5de-f24-d522-46282597703@appl-ecosys.com> <1b139d9a-b95f-f7c8-52fb-9d7442c69ad9@appl-ecosys.com> <97d69b9-48de-3bd4-95d-df5614ff44a@appl-ecosys.com> <4f319e27-0e54-40dd-888f-1e4c856a1b02@aklaver.com> In-Reply-To: From: "David G. Johnston" Date: Thu, 13 Jun 2024 15:29:01 -0700 Message-ID: Subject: Re: Reset sequence to current maximum value of rows To: Rich Shepard Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000d49e2c061acd084e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d49e2c061acd084e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 13, 2024 at 3:13=E2=80=AFPM Rich Shepard wrote: > Yes, I'm sure. Early yesterday I did get duplicate key errors. That's whe= n > I > looked on stackexchange to learn how to reset the sequence's max value to > the value of the number of rows in the table. Not only did my attempt to > add > a single new company to the companies table change all company names in > that > one industry to the new name, but I just discovered that it changed all > rows > in that column to the new company name: > > At present the belief there is a bug in PostgreSQL is unsubstantiated. I suggest you look internally for how an update command that caused the resultant data could have been executed. That is much more plausible, and thus a better use of time, if you want to spend more time on this, than trying to produce the observed behavior again using just insert and setval(...) commands. David J. --000000000000d49e2c061acd084e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 13, 2024 at 3:13=E2=80=AFPM Rich Shepard <<= a href=3D"mailto:rshepard@appl-ecosys.com">rshepard@appl-ecosys.com>= wrote:
Yes, I'm sure. Early yesterday I did g= et duplicate key errors. That's when I
looked on stackexchange to learn how to reset the sequence's max value = to
the value of the number of rows in the table. Not only did my attempt to ad= d
a single new company to the companies table change all company names in tha= t
one industry to the new name, but I just discovered that it changed all row= s
in that column to the new company name:


=
At present the belief there is a bug in PostgreSQL is unsubstantiated.

I suggest you look internally for how an update command= that caused the resultant data could have been executed.=C2=A0 That is muc= h more plausible, and thus a better use of time, if you want to spend more = time on this, than trying to produce the observed behavior again using just= insert and setval(...) commands.

David J.
<= br>
--000000000000d49e2c061acd084e--