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 1vE7Se-005bq0-7z for pgsql-general@arkaria.postgresql.org; Wed, 29 Oct 2025 14:47:40 +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 1vE7Sb-001V0b-34 for pgsql-general@arkaria.postgresql.org; Wed, 29 Oct 2025 14:47:36 +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 1vE7Sa-001V0S-8x for pgsql-general@lists.postgresql.org; Wed, 29 Oct 2025 14:47:35 +0000 Received: from mail-northcentralusazlp170100001.outbound.protection.outlook.com ([2a01:111:f403:c105::1] helo=CH1PR05CU001.outbound.protection.outlook.com) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vE7SW-004OuM-06 for pgsql-general@lists.postgresql.org; Wed, 29 Oct 2025 14:47:34 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lk3aILkbFJyjUTlJJ6UNHMM1AK8fIDAWT+XwLTcxrhwN0BbMUg2/BTUKBt0NEkhYnHThFukYuhdSjgWOTHjN2lTgDDf/AYpG6ALqHVsrQvSuGjTuqYSuUUF9ICi+krKfvpM5Wep3X+WGIWbqLEIu6KgzroK8L0I4FPsNjIr/aQKk501u8c0bVsof076oQ3V0vxa/Ysmqz3txv0QqmdWSv6eD8YVrr//2fvk8ALuzPxlr5VtV95SCvST8/eNs8hnDK91C5N4o6BBqMgnWg9XUvW0dveBsAxqGpUFI0oDRG2iv4LMxM2KRf0ytjWORJS+VksD/S/tua/H7PzYLLWZlyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PpFvqL8y65hsde0oW8EphPdILIwiiwSaYlcZpLHIAzs=; b=EvLEYOdojXzdEdBMbaxKDiYQjPG3EWk0Fd7+NcRz65tjAvj8ucOfxtry0nFK93ZdMw5zDuCiqK1MT06+LM3ynWYzzxKv7M0m5lEJ86NDCZ3TQkZqGeYq+NaWvdgH0XcQHJT1BgUFVoyF8jCHucydqjWB9ZKRJMWBoWPXqF7sSicHnjpwbtkU+7usXvBj/7R0Wy5IK9Dc8IkIfTW+TBFXf6S1k/wMIJuoJgUzp6r5NsN4Rcwx/RzMIDrn8Q64MVW1HSZS0xJXomzXBd/sUtIG/28QJzZmlQKlUWqygYYbPlKaR1OemNw+EDAfBHtJPJ5WaGc1Wx/dKGxqkys5HZiucQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=thepw.com; dmarc=pass action=none header.from=thepw.com; dkim=pass header.d=thepw.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thepw.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PpFvqL8y65hsde0oW8EphPdILIwiiwSaYlcZpLHIAzs=; b=FNepdaQZipVAgjTVcIXzBGN9JbONmHHfez2GixJwPnhHu0jQYCRN55C36tNk4d32m/rSFT6PQDh7tQCMTxbnx1mRjf5H9GC2GnQagXUMcNqYoTp3aQF/o5OisaGnevL5AUFHdhZ+lNIrt9i954MCbc7f4coVbvDQu1k1Xxj9KilQ7gRK7PPkmIERk8GE7rPg3O6R/cRVmW7BJYBdJ6cAEk5EK6Ig9nOZL/MNd+GmpsccABj9PitdjHrG49uGyLwib3SJBwAcrBgC1qUHc3oRTZHl64BDtujjsXC6qqU5D6NAZPLNNnYOiZcjHWPUO0XWN0UVDAbfme65F1q9LOBLUw== Received: from BN8PR07MB5905.namprd07.prod.outlook.com (2603:10b6:408:69::26) by BY5PR07MB7250.namprd07.prod.outlook.com (2603:10b6:a03:20b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9275.13; Wed, 29 Oct 2025 14:47:24 +0000 Received: from BN8PR07MB5905.namprd07.prod.outlook.com ([fe80::6c92:be07:f146:c63b]) by BN8PR07MB5905.namprd07.prod.outlook.com ([fe80::6c92:be07:f146:c63b%5]) with mapi id 15.20.9275.011; Wed, 29 Oct 2025 14:47:24 +0000 From: kurt thepw.com To: Colin 't Hart , PostgreSQL General Subject: Re: Two sequences associated with one identity column Thread-Topic: Two sequences associated with one identity column Thread-Index: AQHcSMcgK4OvlbsN6Eigz34vjyB0QbTZBl4AgAABSKuAABnagIAABm/h Date: Wed, 29 Oct 2025 14:47:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=thepw.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BN8PR07MB5905:EE_|BY5PR07MB7250:EE_ x-ms-office365-filtering-correlation-id: 7ab45503-a507-4300-7fac-08de16fa12d6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021|8096899003; x-microsoft-antispam-message-info: =?Windows-1252?Q?MDLgF8TLOcQUiax3SgsRefuSrHMTkdD4QBjQ8aCq3QI+mKlkpE8WKqyK?= =?Windows-1252?Q?9u4pIGiAyvve+qo8bCHrie9muJfZPQ7uA5O7l4yfQ3vya/DTuTupoZ2Z?= =?Windows-1252?Q?KXmV91VjV1GxBpKR3ix9fd8vLG2BnUxFvGM3QD2IniFeXGAKecUnK6Nw?= =?Windows-1252?Q?4yz+2vG7kzSVdUhWGO4RMIrzvNJUAxYoNNIpgDXF+aePwVz0YiWlJjGL?= =?Windows-1252?Q?yE5lh7JnzAFDcq259v34ENar91nKcamPxpFOUg17hs5nTtErrrHKkBhi?= =?Windows-1252?Q?e1dL3oHXeo83wMZ+OqwP0uzGAP6oFpTJlZE5dnmrdrGlUxeD6PrklMOt?= =?Windows-1252?Q?wqD/L6FsGzgybawMbx8AZEBKEhhgg8JTvUsDZjzq+agPzDZBDVZ3x1tT?= =?Windows-1252?Q?lPIXDATAP7qTqBFGzpV3fQZ89zjuhy78khRiOWUG9hXRqIkJv4yZmxaX?= =?Windows-1252?Q?Nabl+ZpIckLnvNju4VLuMGewPCKD9jkBbCF2qpOBnamEvfHphU4COjZ7?= =?Windows-1252?Q?dFeZaMywLWh699MRFBhRCndzwVdEkFfZBsmYp3tjaTvwyCrA9qpYe9VW?= =?Windows-1252?Q?tO5rGCSR9O6bg4fJmpyRl0iCbx7xYzF1ocwfIjK9odokVpOZLSX7KlE7?= =?Windows-1252?Q?HTU/C/Ibe7WsAqHvXXomziiEDPlTEeyGDRKnpdhN/mrH1Zl2pQxDX7vb?= =?Windows-1252?Q?Q0Fn0/qxYlrzCdG8kHNONJyEPdMuFRBGdv0bAbZhBLvwF0P2DqwrPDet?= =?Windows-1252?Q?igIiXAUICKKVDXnbMRpwOR3gVk2QntKvR7/leSf85I2517qmCphLQ+A8?= =?Windows-1252?Q?7u+7h+ca6u4Wx23EUbQ3tt6xFM55YJY84cj5sCdK+cD5Ov+jqGe1R+MJ?= =?Windows-1252?Q?J79Vn5htklcHyznNPE9rGxfo5Xp+5dyxLoEHiuCsbTQ3W0K0g3XScjEz?= =?Windows-1252?Q?V3YCah/EP6VK6wcNFjStwFjnAaaJPxH0eYDzV9R5gKYqV5Do23a29h8L?= =?Windows-1252?Q?egXUOgC0aBqmUtLoIV84JhCs5kCE1YUxcLMIcac66BccUyU+aH7spfkl?= =?Windows-1252?Q?B1qZ5EOgT7LKi7u9EwqZHh6W/obM7d2qxAYr4OnJVGe+MJY1WCPBz0PC?= =?Windows-1252?Q?9kslOz8NUQwSSMg5B9S3E7uW+S1YQWgJ+DhPsLOhCnh4CocdUgIA3ine?= =?Windows-1252?Q?6cM/mxcRwUucWEoWKNehH1dI1wE/DOqZSPyWNrHPEvU4ylqmcqC6E6Zu?= =?Windows-1252?Q?3r/I32T8P4AXf/GPS5BShu37ZfRS49zhBdodZ9Kbyws0RJTzCIStPt/V?= =?Windows-1252?Q?RiNrAbvz11MtKrqeG/GGxQefpcZ2PXaF2mZ1KuJigZ881Oftu9itW4HR?= =?Windows-1252?Q?2q0Sdc58qRzNywToP+gYOlR1fKkk0zq7yyQPk4BwELhabYjbXsUjslE3?= =?Windows-1252?Q?oVAtuKAX1E57++0yDvnfgM+nWiAcTxE0NnpphLNtg+8x56UR5Ad6zFNf?= =?Windows-1252?Q?lLBtwk+ERr3eJnYsTtP7fpqTIkEUXth+2dOQRCvK1+NGtTQTx9y7QUNW?= =?Windows-1252?Q?euEH9cmzfPhQxgJ179iiML9hNNDkO5HEA9iqZJG8/QqxR1RTuTqGYm+m?= =?Windows-1252?Q?86awbdmVrwMAzyW00kNSvjNe?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN8PR07MB5905.namprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021)(8096899003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?OUyxK154ibIw4wkLSWl53jInXysMW+nYQto5nOl+DLHJ2ZCCXO3+DDU6?= =?Windows-1252?Q?Wag+EQrdIdmfCa4OeGfBX3p4ArjNG9tQUfJ/jYwAyEjrySHdqaNv18ei?= =?Windows-1252?Q?bhA3JT/WkKcKbpdHk5WescmeC8X3pgxYOAgrq4AZ6wMrmqDju41MmE65?= =?Windows-1252?Q?2dx7RbicjSeoVbsGkMC0coMhKBC/tZGMgfHiecyN70GOOQ1wye9lZO6I?= =?Windows-1252?Q?JUiQsnE2RzmirMpk9B6bIVLdswUka8C7lnefA6/yJcg+Zj0iu30Wyi8L?= =?Windows-1252?Q?XYsQgE62oFOnKDwWZhBIFxhWDBJNs76N5yYizy3UdDaxiJwTxqjXd6b/?= =?Windows-1252?Q?Zy8Yadrtpq30rkoA02kEk8c77Cof/QsfzU2RAwLrh7JlhpGFgTlVDDDG?= =?Windows-1252?Q?QIS3fB4TEMJkY7rRq2Vn1qz/PrGCNP0vHyNBzQD2FNUXmJ+2l63tMI90?= =?Windows-1252?Q?BjXu37mA/WIK6vZ8g/DJcY5bTuI8e+gDn0Mf8Y3weeGaBonkpWjRlfXq?= =?Windows-1252?Q?4LRVVQzqw/jEZTYNcfyOvKcZia+x2P/vP6m1jRrYHiSEOL8SFSDgJe/p?= =?Windows-1252?Q?SPf6j85OO8WhoKtSC1b51lILvQ32+5RdMkVf2ds6BiMsU1ie5sdCdC42?= =?Windows-1252?Q?sFdU/63pJwpqx1OE3G5qNa5R3E9kyTc97lrHK5XVQ3IYq85uhZ+OgKto?= =?Windows-1252?Q?5U10+wloaNq4L2axxXmgJ0EvLFxeLWrLbwxs7eiM/oJh0y+2qEZmkDOs?= =?Windows-1252?Q?8w0kmpY5UPQyNBpvaas3C/suG6oiRUF5u+fq2xLIVC9CjTq+D/89e3kr?= =?Windows-1252?Q?iz9hURuCpUpZpaqJ9wEP7P7IoNkBGwVO1xQ3Xk3tIv0lwcEkZSYet7PH?= =?Windows-1252?Q?rMXmjrFOVHiSxa8JwiEVIFxClRqhhiWpxeOphgxRtlYr5UcbrpiusfJO?= =?Windows-1252?Q?qOFhFXVcqCvZ0d9PM4IfF6HdRdBbyriWLedHlyJPIW6z1JAaprrpi48C?= =?Windows-1252?Q?y8wJsb7xRMTpxGVpewVTrQU5pFTpmVy2f/WCwmdjxZfWS/1WPIkocAmI?= =?Windows-1252?Q?X0w0mwhFMqz2Xv0P2Sp5sgWjWOp1QUWkRD7dd83WpN8A1jKfyAl/kjy7?= =?Windows-1252?Q?hrS25CPmjICzCH0rMADZkYoYL59TeQDEdfCTOESK5hFmImoorfECeB0Q?= =?Windows-1252?Q?sjVUUfykrLJnbVNojFV5/2yCQgmNhhBNL1ElBbxHNNqmcostlpumlvUH?= =?Windows-1252?Q?Xd1eo+C1DEgI72fxq3coyKk+UFUynegbhS1qFJuT2hz1xIiw1/UjEu/5?= =?Windows-1252?Q?5x9yHGGKeHwE54t4n5s3lAZ3sh8wUaMk9fusQYetGd4KIPUVDlgN9x+e?= =?Windows-1252?Q?kTvvyXVp6uNeTAYobkNYjaEQ84ys/yFbMjsxXbmqiU5DXvBSKnq0Zdeo?= =?Windows-1252?Q?xMWZR0xNcVGCFCaoNDSCvxpEyTSiNS+mWuMD0EH50PNCaymuLl2+Sekq?= =?Windows-1252?Q?3wSQVkqLNOHmu6mehgUQWOOb08NCKSoYI0d97mG0r/Wmt9YKWnLSYnk6?= =?Windows-1252?Q?GClT+tQtkYGdrbMF0xE9WbEFGNtflutnSVRl4Xu/CddxTXkbN48tFVel?= =?Windows-1252?Q?Vc4x1YJNEr3D+6CjDdUwQahqD0f8cYosMkLEEjGv40+AXh/tB1Id40dV?= =?Windows-1252?Q?ON3QOBvT2tU=3D?= Content-Type: multipart/alternative; boundary="_000_BN8PR07MB5905FE3F05381DDBFFDEDA9FD3FAABN8PR07MB5905namp_" MIME-Version: 1.0 X-OriginatorOrg: thepw.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR07MB5905.namprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ab45503-a507-4300-7fac-08de16fa12d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2025 14:47:24.5893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2b55f125-3527-485e-ac77-3a5c553302cd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: C+XNMNSVMzKumQSBAdnVAEw2GCc4MRoohOEzKzhmzfEp7vYg+PCAVRja9oxknsbf X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR07MB7250 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_BN8PR07MB5905FE3F05381DDBFFDEDA9FD3FAABN8PR07MB5905namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable < < CREATE TABLE . ( < , < id bigint NOT NULL < ); < I've never seen a plaintext pg_dump output where the sequence associated w= ith a column in a table was not mentioned in s "DEFAULT nextval(..." modifi= er in that column's line of the CREATE TABLE statement, ex: < < CREATE TABLE . ( < id integer DEFAULT nextval('.'::regclass) NOT NULL, < ..., < . . . . . < ); With the sequence already created earlier in the dump file. But then, I've = never before seen a table column with two associated sequences. Maybe that = is what makes pg_dump generate the "ALTER TABLE . ALTER COLUMN id ADD GENERATED..." Statements. < < 1. The id column is last, so quite possibly added later (instead of < the original PK which was dropped?) < That seems likely, and probably the 2nd sequence was added in by someone wh= o didn't know (or forgot) about the first one. < < 2. The two sequences are just dumped -- which causes an error when import= ing. < I'd be curious to know if simple editing out the 2nd "ALTER TABLE...ADD GEN= ERATED.." statement would allow a restore of the database to succeed. pg_re= store dorsn't work with plaintext files, you have to cat them into psql or = use the '-f' switch. < < A third thing that is interesting is that I can drop the table just < fine -- and both sequences get dropped along with it. < The table seems to be relatively small -- and has no foreign keys -- < so I think the solution will be to recreate the table (create table as < select), drop the original table and finally rename the new table the < same as the old one. < That's probably the quickest way to fix it, though if you are "create table= as select.."-ing from the old table you might get the two sequences again.= I've never used "create table as select" . An alternative might be to pg_dump just that table, edit the .sql file, dro= p the table, and then restore. Kurt ________________________________ From: Colin 't Hart Sent: Wednesday, October 29, 2025 9:40 AM To: PostgreSQL General Subject: Re: Two sequences associated with one identity column As expected the dump contains: CREATE TABLE . ( , id bigint NOT NULL ); -- -- Name: ; Type: SEQUENCE; Schema: ; Owner: -- ALTER TABLE . ALTER COLUMN id ADD GENERATED ALWAYS AS IDENTITY ( SEQUENCE NAME . START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1 ); -- -- Name: ; Type: SEQUENCE; Schema: ; Owner: -- ALTER TABLE . ALTER COLUMN id ADD GENERATED ALWAYS AS IDENTITY ( SEQUENCE NAME . START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1 ); Two things are interesting: 1. The id column is last, so quite possibly added later (instead of the original PK which was dropped?) 2. The two sequences are just dumped -- which causes an error when importin= g. A third thing that is interesting is that I can drop the table just fine -- and both sequences get dropped along with it. The table seems to be relatively small -- and has no foreign keys -- so I think the solution will be to recreate the table (create table as select), drop the original table and finally rename the new table the same as the old one. Also checking to see if the problem extends to the other environments. /Colin On Wed, 29 Oct 2025 at 13:07, hubert depesz lubaczewski wrote: > > On Wed, Oct 29, 2025 at 01:04:48PM +0100, Colin 't Hart wrote: > > Thanks. But as I wrote above, trying to alter either of the two > > sequences and specifying "owned by none" results in the error. > > Sorry, missed that. > > Can you please provide pg_dump output from this db, just schema, just > this one table, and both sequences? > > Or, how did you arrive at this situation? > > Did you try to alter table =85 alter column =85 drop identity; > > Best regards, > > depesz > --_000_BN8PR07MB5905FE3F05381DDBFFDEDA9FD3FAABN8PR07MB5905namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

<
< CREATE TABLE <schema>.<tablename> (
< <other columns>,
<   id bigint NOT NULL
< );
<

I've never seen a plaintext pg_dump  output where the sequence associa= ted with a column in a table was not mentioned in s "DEFAULT nextval(.= .." modifier in that column's line of the CREATE TABLE statement, ex:<= br>
<
< CREATE TABLE <schema>.<tbl> (
<    id integer DEFAULT nextval('<schema>.<seqname>= ;'::regclass) NOT NULL,
<    <next column>...,
<   .  .  .  .  .
<  );

With the sequence already created earlier in the dump file. But then, I've = never before seen a table column with two associated sequences. Maybe that = is what makes pg_dump generate the

"ALTER TABLE <schema>.<tablename> ALTER COLUMN id ADD GENE= RATED..."

Statements. 

<
< 1. The id column is last, so quite possibly added later (instead of
< the original PK which was dropped?)
<
That seems likely, and probably the 2nd sequence was added = in by someone who didn't know (or forgot) about the first one.

<
< 2. The two sequences are just dumped -- which causes an error when imp= orting.
<
I'd be curious to know if simple editing out the 2nd "= ALTER TABLE...ADD GENERATED.." statement would allow a restore of the = database to succeed. pg_restore dorsn't work with plaintext files, you have= to cat them into psql or use the '-f' switch. 

<
< A third thing that is interesting is that I can drop the table just
< fine -- and both sequences get dropped along with it.
< The table seems to be relatively small -- and has no foreign keys --
< so I think the solution will be to recreate the table (create table as=
< select), drop the original table and finally rename the new table the<= /div>
< same as the old one.
<

That's probably the quickest way to fix it, though if you are "create = table as select.."-ing from the old table you might get the two sequen= ces again. I've never used "create table as select" . 

An alternative might be to pg_dump just that table, edit the .sql file, dro= p the table, and then restore.

Kurt

From: Colin 't Hart <col= inthart@gmail.com>
Sent: Wednesday, October 29, 2025 9:40 AM
To: PostgreSQL General <pgsql-general@lists.postgresql.org> Subject: Re: Two sequences associated with one identity column
 
As expected the dump contains:

CREATE TABLE <schema>.<tablename> (
<other columns>,
    id bigint NOT NULL
);

<snip>

--
-- Name: <sequence1>; Type: SEQUENCE; Schema: <schema>; Owner: = <owner>
--

ALTER TABLE <schema>.<tablename> ALTER COLUMN id ADD GENERATED = ALWAYS
AS IDENTITY (
    SEQUENCE NAME <schema>.<sequence1>
    START WITH 1
    INCREMENT BY 1
    NO MINVALUE
    NO MAXVALUE
    CACHE 1
);


--
-- Name: <sequence2>; Type: SEQUENCE; Schema: <schema>; Owner: = <owner>
--

ALTER TABLE <schema>.<tablename> ALTER COLUMN id ADD GENERATED = ALWAYS
AS IDENTITY (
    SEQUENCE NAME <schema>.<sequence2>
    START WITH 1
    INCREMENT BY 1
    NO MINVALUE
    NO MAXVALUE
    CACHE 1
);


Two things are interesting:
1. The id column is last, so quite possibly added later (instead of
the original PK which was dropped?)
2. The two sequences are just dumped -- which causes an error when importin= g.

A third thing that is interesting is that I can drop the table just
fine -- and both sequences get dropped along with it.

The table seems to be relatively small -- and has no foreign keys --
so I think the solution will be to recreate the table (create table as
select), drop the original table and finally rename the new table the
same as the old one.

Also checking to see if the problem extends to the other environments.

/Colin



On Wed, 29 Oct 2025 at 13:07, hubert depesz lubaczewski
<depesz@depesz.com> wrote:
>
> On Wed, Oct 29, 2025 at 01:04:48PM +0100, Colin 't Hart wrote:
> > Thanks. But as I wrote above, trying to alter either of the two > > sequences and specifying "owned by none" results in the= error.
>
> Sorry, missed that.
>
> Can you please provide pg_dump output from this db, just schema, just<= br> > this one table, and both sequences?
>
> Or, how did you arrive at this situation?
>
> Did you try to alter table =85 alter column =85 drop identity;
>
> Best regards,
>
> depesz
>


--_000_BN8PR07MB5905FE3F05381DDBFFDEDA9FD3FAABN8PR07MB5905namp_--