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 1tqYmw-006rTX-BU for pgsql-general@arkaria.postgresql.org; Fri, 07 Mar 2025 14:34:58 +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 1tqYmu-006M2G-VD for pgsql-general@arkaria.postgresql.org; Fri, 07 Mar 2025 14:34:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tqYmu-006M22-Dx for pgsql-general@lists.postgresql.org; Fri, 07 Mar 2025 14:34:56 +0000 Received: from mail-mw2nam12olkn20812.outbound.protection.outlook.com ([2a01:111:f403:2805::812] helo=NAM12-MW2-obe.outbound.protection.outlook.com) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tqYmq-001VmV-1r for pgsql-general@postgresql.org; Fri, 07 Mar 2025 14:34:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ijfh+zRyl2tlTm7nCroGq04gMGtuNXJAGgJJUbLNZExsvOJS3LqnicB2vZpf/9b19lXOy33zQDiGswmhKbGwg2ODgo39Vz9YmemWMLjVRxm9T8HjFu+9VceVQguwczocCls4gF8+rOqseLV6diCiG5GTr7LNrL8PqtY/Zt+IgSvD+5nuLTOyozZZi3WFdFUtACIsIbCsB+6eecGS/d6VtuMIZfAUHBZD7SD7g5KS8sXlUPMf371xVYblIdTYSNewiHA9lUijvkz7O5QYtXRHJLa+0VyU5eRzkFEDadBZlkJUNqUzlOhnWP37I+mUj7zMDO8IeRtNCUAw527O+dExXQ== 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=UR6Cf6LIA6q6NdJjSbBw7DMYGZjUonKAx3p0CjmL79U=; b=Q4uaG+I7l0mGHs0QVb8L5Yxcj8uKKvp4bWzpHNCe706dvmFKKe3j1+dmMqxgS5yzAQZaU4/d74a9oKrt7n+gpqtZxYFsTQJgkSH4/EAWkkscWmAWQmNI2E4LKyp5K0VehIY+ITP8AR+6BgrWiscxz9hAGaBDG5ueYzSNb1Yo1dUGazUxAIonxFBaqUw61CjrsWabOqNDNH0MRGpKv/jVNDmAEya7JDEAaNSyLF0vLksh7eTKzOqdKvGQxnafE4751LhWl18NQmgdN570c/eNBBv/31odnPfwzZung2sUJIZF0ULqdieiRWgIuVGxdsU81iSKRasEYblSrWBPnf3VAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UR6Cf6LIA6q6NdJjSbBw7DMYGZjUonKAx3p0CjmL79U=; b=fMenfZ/LmIDAic7HhlqfYw9iqar6UiOD59sxD78nJ3SXjkqFTXg+H9+9VsKb0MGEJiIA/BOYSi9GggEQRtakyJplIkDNry4blBAqf5f0dcqorQs/Yd+2qblbNWhQmx9R/YUkm2WPSnfTesXd+sNo7Vvhl2B5c8+axYcWGGzK5SEPpJTDqKLPLXf5cGTegqv/9PUh3FDe4qIDjS1kP2peaW3tezRz0dBVohmTEzfxSgP8Jsy9FcaBHPIcmm5D1oGeqz5CbhOx3TaK13vhA0eRghRqH0D/LgOeNe3sOlrv4OB0XF3Ggwz4FdndCAq1dZ605NHZOt4FkNepHxcWm7NVaQ== Received: from SJ2PR22MB4328.namprd22.prod.outlook.com (2603:10b6:a03:547::6) by CH3PR22MB4465.namprd22.prod.outlook.com (2603:10b6:610:1a0::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8511.22; Fri, 7 Mar 2025 14:34:50 +0000 Received: from SJ2PR22MB4328.namprd22.prod.outlook.com ([fe80::2440:4b5e:d794:94e]) by SJ2PR22MB4328.namprd22.prod.outlook.com ([fe80::2440:4b5e:d794:94e%6]) with mapi id 15.20.8511.015; Fri, 7 Mar 2025 14:34:50 +0000 From: mark bradley To: Adrian Klaver CC: pgsql-general Subject: Re: Duplicate Key Values Thread-Topic: Duplicate Key Values Thread-Index: AQHbjfSQTi8IT+qnIE+vrsDEftWknrNk0i6AgABZWESAAAeigIAAA0qAgAEyu6OAAAQ9gIAACBsIgAAUTYCAAACl9oAACBWAgAEp+ik= Date: Fri, 7 Mar 2025 14:34:49 +0000 Message-ID: References: <36356aa1-1a5c-44af-a1c0-f190249812ca@aklaver.com> <6aee94f9-d421-4622-bccc-bdac37969be0@aklaver.com> <75b33741-ee99-4524-b63a-edad21c1266d@aklaver.com> In-Reply-To: <75b33741-ee99-4524-b63a-edad21c1266d@aklaver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ2PR22MB4328:EE_|CH3PR22MB4465:EE_ x-ms-office365-filtering-correlation-id: eece180e-a16a-48b4-f759-08dd5d853785 x-microsoft-antispam: BCL:0;ARA:14566002|8060799006|15030799003|12050799009|9400799030|461199028|15080799006|13031999003|7092599003|8062599003|19110799003|10035399004|4302099013|102099032|3412199025|440099028|41001999003|1602099012; x-microsoft-antispam-message-info: =?us-ascii?Q?5HMlOt6G0vjgHcVuWctEI/WY81a+ibCLh2ce4kGPh8+h80iQWDR/kcA+Ynj0?= =?us-ascii?Q?9AyY4HKjbHJijAvXTQ3TdEHEOAuf8mU7m6TRggbdY3Hy+eR0HRhiWM8UOUOc?= =?us-ascii?Q?GNiJj9VW0c6lN2hAfLgYV9bX63x3Q/fII4aGK43cOJ1xe6BfzBDrRtVdpRJ3?= =?us-ascii?Q?qW3b4rXZeQvW39bbLHAOzJQI2h4/YLXbjcAmBlotxSpS9G/t8eWdOcdUj6lW?= =?us-ascii?Q?XHi5G6NLFHMhxkUiRer9pR1J31U5YX9iySe6JA3ZoWgb7feH5iTq0eR6NNKp?= =?us-ascii?Q?ZzKj5EQYjgyvTfexHDzxJyyJm+Bvl51KXHciBj9WlgPbeKsAbe5kH4uocjFe?= =?us-ascii?Q?KlTVWGBnakVN0LX19WjY/kbVad2iKQVXiXO8cJqdV0JeyYtFPxqfq3ogrsKP?= =?us-ascii?Q?o6QoGQ/CNaYFOtEeVqb5mqZPUZJDKyhoydqGYgMbDs8AVfZ+zVuS/NnrNf3P?= =?us-ascii?Q?TkX6H6EUd4RPllfUe2bv+e/H7Zs7wcZwSiMU7rBJjAbmG0r/a6uRR6adBVYP?= =?us-ascii?Q?2PlqfXVLst/E6LHUnpEsSgXJMhoX3L0oSQP3NIStmYFNVFWyXGRQEM23ZalE?= =?us-ascii?Q?BlMZD6+UN+mvo7ooJAA3JU63VMlBh/IZYjjmSuE2XOHenX1LIgycWNWNoodA?= =?us-ascii?Q?/ioRkXdNrq5h3cwm7vsqRHL2LQUsov87oYfq6dKtwxA0Bci+w65NJ/8aoMNQ?= =?us-ascii?Q?ylCklV9FMYRT4ik5ndd4ILBR5ml9TuWPE4JzD9DkWdH8NsWmxZhof7pG0YJ2?= =?us-ascii?Q?CMNpcZPYt0Gv34CeokW+V/5kG1Am13nc6xTSBP4q55/Vwy4hsIobdEYB1IIK?= =?us-ascii?Q?P2MYCMX+/m9n3FAURYwZenGtHakqkbcB/ZicqkkFnTvVrW0PvRbGMhhY8ijs?= =?us-ascii?Q?JLAJ3OOgVOYhLZ7G0MYLv6cGWZvMk8oizQfsxevyME7ipar7lByuwZCmV4Hs?= =?us-ascii?Q?e75HqWSlfanF6XlpQec7UEv4Trs7f/oRZO+6z2MxVMVPeV1a9N89H0rXc4+3?= =?us-ascii?Q?a9hembZ2VcZXiJsX118q03Bpe/J3r/6svlSBorPOypi1pbDQOfQRPqMag8zx?= =?us-ascii?Q?KYLvy96+d5YhKPwdvooVAjqZEBWnetE6RJALsbZLsrdMD8ZRcfvPxEW9BUss?= =?us-ascii?Q?HONSVAaaOnq15OLTEwZ+Jf9RUN5FlGW1eSkingjqXoBlKq6xSClHSoGr+48h?= =?us-ascii?Q?kwh/E3M/aeA4rU3DbIvidXDu3m2F833lcQx/ajJ6ZhjPceEisxoR+/H+gsJB?= =?us-ascii?Q?PHkmRJeI8vCC7ISVmbx1JqaN5x4sRSukZvZyQnNWvXmIsECl+9KQBMglTAMT?= =?us-ascii?Q?s0rEEPCvN7PpvfXOVnPY3l3DPQE3m04KyoZon2y4XqAnZfV8GSuOJEIcv7hE?= =?us-ascii?Q?e32lg0Q=3D?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?hW8z1LREtVZBPG/KapLBzeCFmtLFx96ggTVZMSlVL0zxwdQ0jUID576YlX3n?= =?us-ascii?Q?KaQTM7ZhKu0U001fwJ+AB2UcccDTOPj2qRwDaPrfVP07bjToN55f9UHMI1En?= =?us-ascii?Q?q4lCOAqiMSuXhz8x0lRIRBcIpeDFLUIRG6J8KluF3YzEWY2ZoQKwNPhe4j7u?= =?us-ascii?Q?xqDGUAKzm4YXiChukMSmL+5EZg92pP0G3s/qZI2pfrjnlcKb7TDmnowVUlBg?= =?us-ascii?Q?OIutho1qFEMN5k1MyrUF+YRe1a8eTiabq5NbVRN4md62H/hAiPWkHExyXB0u?= =?us-ascii?Q?2OaYmEQOXrPeSW1wQMz/mtChvUluwOYqDUnNUfwXKpvulVglsEBUgZ9faun5?= =?us-ascii?Q?LLeb2frQqx6D74KZ6P5xri4cXvgc5ucWi98FHRp57C/n9Mi0vrF+u4lvNfqd?= =?us-ascii?Q?FJLAGT/uc9vrkmt44fUpQiwzlhCYwvt9ny/IQK/hj8i8Smq2gxdNU3gKJ3RU?= =?us-ascii?Q?qEfnhE4gWSJSL90UVT5HCocUHY8yRsCpcjDKbFERupbURUftlnlsx8+tcbTt?= =?us-ascii?Q?Fa6YDHknAaVzP4IJSdMYPN3W2cnuEm25SsL6uzXQf3aWUvxymJK7w3SC5odR?= =?us-ascii?Q?noDuQKAEXsMNVQu3EL4mztNflOU1wJ72ybwkK50EOcXm1p4zaaRWPabReP2/?= =?us-ascii?Q?39MIEaEoWywtQdCe2oSpc6VvjTfmmdyEBprc7Sl8xl7F0sBDyuxLHpyxKfkc?= =?us-ascii?Q?dgJTeMo8FXFCx7xJWbmwEIG74nC9fcCUJ98BV6PqEOxzyJ/GEWaVXRjPxSvc?= =?us-ascii?Q?3NcWXdYfxtNk37zie4MGJHrEEha25TXHcXZ52GuLIsN7HevVtRorMmY/VMTx?= =?us-ascii?Q?sDbLctr4LwfyKNID89RTQ12AJcj7ZYI9VjImvPb3Cox/tC4I7m7u99jzsimI?= =?us-ascii?Q?mCu9RI76+0vVnsVWpf0qlJwkk9voehRu9A3K4UEdzxiEN4XX4It8Y5iVXPR9?= =?us-ascii?Q?H5bYyDxJHAM0zAz5uQX4TpQPLlM3ksrwjePF7GjY+Hyku4X5g4VQJ6hXih42?= =?us-ascii?Q?TLZ3nhFEJ8AlFvv9gN8R2VbxD088StQWpkjtDoRkWUb/TSBlO6MxIBYnLHL2?= =?us-ascii?Q?DPu5dZJJILzSFyAincNQ4LbLCuYFrfpkoqMwty4kgS/h8Df+yVryCaUuLqRD?= =?us-ascii?Q?MqWnz4uTBqA6G/KPWqmk64KR91Kg634dP1fk9DRFlu5VaaoKyuio9S077D03?= =?us-ascii?Q?Edh3smqeB7K5VFhojeEscmhZaatDSiPKzC7W6F1l1uMzDJtti9RPr2YkGvU?= =?us-ascii?Q?=3D?= Content-Type: multipart/alternative; boundary="_000_SJ2PR22MB43286857EAC74D1EE332B08CBAD52SJ2PR22MB4328namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ2PR22MB4328.namprd22.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: eece180e-a16a-48b4-f759-08dd5d853785 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2025 14:34:49.9766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR22MB4465 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_SJ2PR22MB43286857EAC74D1EE332B08CBAD52SJ2PR22MB4328namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is what MS Copilot has to say about this apparent bug where Postgres i= nserts extra rows violating a primary keys uniqueness constraint: Yes, this issue has been encountered by others. There are a few potential r= easons why this might happen: 1. Sequence Out of Sync: Sometimes, the sequence that generates unique values = for the primary key can become out of sync, especially after a bulk import = or a database restore. You can check if the sequence is out of sync and res= et it if necessary. 2. Index Corruption: Index corruption can occur due to various reasons, such a= s hardware failures or bugs in earlier versions of PostgreSQL. This can lea= d to duplicate primary keys being inserted. 3. Table Inheritance: If you are using table inheritance, primary keys are not= enforced among inherited tables. This can lead to duplicates if not handle= d correctly. 4. Application Logic: Sometimes, the application logic might inadvertently ins= ert duplicate records. Reviewing the application code and insert statements= can help identify and resolve such issues. To resolve the issue, you can: * Check and reset the sequence if it's out of sync. * Rebuild the index if it's corrupted. Any of the first 3 could be involved. There isn't an application involved = other than pgAdmin. 1. Originally, the key in the node table was a sequence, but I changed it to a= non-sequence. 2. There is no index on the primary key node_id, and I understand there should= be one. 3. I didn't explicitly use Postgres inheritance but there are two tables that = are subclasses of node. There are dataset nodes and processing_node [s] ta= bles. Each is a type of node and have primary keys that are foreign keys f= rom the node table. This key is node_id. What to do? I hesitate to just delete my tables and start over because thi= s error will reoccur. Best regards, Mark Brady amazon.com/author/markjbrady ________________________________ From: Adrian Klaver Sent: Thursday, March 6, 2025 3:34 PM To: mark bradley Cc: pgsql-general Subject: Re: Duplicate Key Values On 3/6/25 12:06, mark bradley wrote: My mistake I forgot to Cc list on my previous post, which was: That would be an issue and also would mean it is not a PK. In psql do: \d dataset and show the results as text in your reply. Ccing list The below shows there is an index("dataset_pkey") on node_id. Note, reindexing will take a lock on the table that prevents changing data while the operation is running. See the below for more information: https://www.postgresql.org/docs/current/sql-reindex.html If the table is not to big and you can interrupt access to it then the simplest command to run would be: REINDEX TABLE dataset; > Universal Metadata Schema=3D# \d dataset > Table "public.dataset" > Column | Type | Collation | > Nullable | Defau > lt > ---------------------------+---------------------------+-----------+-----= -----+------ > --- > node_id | integer | | > not null | > dataset_name | character varying(25) | | > not null | > notes | text | | > | > dataset_type | database_type | | > not null | > dataset_maturity | database_maturity_type | | > not null | > disposition | disposition_type | | > not null | > start_date | date | | > | > end_date | date | | > | > most_recent_update | date | | > | > update_periodicity | interval | | > | > system_of_record | text | | > | > point_of_contact | integer | | > not null | > dataset_url | text | | > | > classification_level | classification_level_type | | > not null | > physical_location | text | | > | > quality_control | yes_no_type | | > not null | > dataset_documentation_url | text | | > not null | > description | text | | > | > node_type | node_type | | > | > dummy | integer | | > | > Indexes: > "dataset_pkey" PRIMARY KEY, btree (node_id) > Foreign-key constraints: > "node_id" FOREIGN KEY (node_id) REFERENCES node(node_id) NOT VALID > "poc" FOREIGN KEY (point_of_contact) REFERENCES poc(poc_id) NOT VALI= D > Referenced by: > TABLE "dataset_table" CONSTRAINT "dataset" FOREIGN KEY (node_id) > REFERENCES datas > et(node_id) NOT VALID > TABLE "dataset_subject" CONSTRAINT "dataset_subject_node_id_fkey" > FOREIGN KEY (no > de_id) REFERENCES dataset(node_id) > TABLE "system_dataset" CONSTRAINT "system_dataset_node_id_fkey" > FOREIGN KEY (node > _id) REFERENCES dataset(node_id) NOT VALID > Inherits: node > > > Best regards, > Mark Brady > _amazon.com/author/markjbrady _ > ------------------------------------------------------------------------ > *From:* Adrian Klaver > *Sent:* Thursday, March 6, 2025 3:03 PM > *To:* mark bradley > *Subject:* Re: Duplicate Key Values > On 3/6/25 10:51, mark bradley wrote: > Reply to list alos. > Ccing list. > >> Looks like there is no index on node_id at the moment > > That would be an issue and also would mean it is not a PK. > > In psql do: > > \d dataset > > and show the results as text in your reply. > >> >> >> Mark Brady, Ph.D. >> Deputy Chief Data Officer, TRMC >> _amazon.com/author/markjbrady >_ >> ------------------------------------------------------------------------ >> *From:* Adrian Klaver >> *Sent:* Thursday, March 6, 2025 1:22 PM >> *To:* mark bradley ; Ron Johnson >> ; pgsql-general >> *Subject:* Re: Duplicate Key Values >> On 3/6/25 10:11, mark bradley wrote: >>> Here is the table definition: >>> >>> >>> And here is the error message I get when I try to delete a duplicate: >> >> Please answer the following: >> >> 1) Did you not see duplicates with the old version of pgAdmin4? >> >> 2) What do you see if you use psql? >> >> 3) Did you upgrade/move the Postgres server or the underlying OS? >> >> 4) Have you tried reindexing the node_id field? >> >>> >>> >>> Mark Brady, >>> _amazon.com/author/markjbrady > >>_ >>> -----------------------------------------------------------------------= - >> >> -- >> Adrian Klaver >> adrian.klaver@aklaver.com >> > > -- > Adrian Klaver > adrian.klaver@aklaver.com > -- Adrian Klaver adrian.klaver@aklaver.com --_000_SJ2PR22MB43286857EAC74D1EE332B08CBAD52SJ2PR22MB4328namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is what MS Copilot has to say about this apparent bug where Postgres i= nserts extra rows violating a primary keys uniqueness constraint:

Yes, this issue has been encountered by others. There are a few potential r= easons why this might happen:
  1. Sequence Out of Sync= : Sometimes, the sequence that generates unique values for the primary = key can become out of sync, especially after a bulk import or a database re= store. You can check if the sequence is out of sync and reset it if necessary.
  2. Index Corruption= : Index corruption can occur due to various reasons, such as hardware failu= res or bugs in earlier versions of PostgreSQL. This can lead to duplicate p= rimary keys being inserted.
  3. Table Inheritance: If you are using table inheritance, primary keys are not enforced among = inherited tables. This can lead to duplicates if not handled correctly.
  4. Application Logic: Sometimes, the application logic might inadvertently insert duplicate re= cords. Reviewing the application code and insert statements can help identi= fy and resolve such issues.
To resolve the issue, you can:
  • Check and reset the seq= uence if it's out of sync.

  • Any of the first 3 could be involved.  There isn't an application invo= lved other than pgAdmin.

    1. Originally, the key in the node t= able was a sequence, but I changed it to a non-sequence.
    2. There is no index on the primary key node_= id, and I understand there should be one. 
    3. I didn't explicitly use Postgres inheritance = but there are two tables that are subclasses of node.  There are dataset nodes and processing_no= de [s] tables.  Each is a type of node and have primary keys = that are foreign keys from the node table.  This key is node_i= d. 

    What to do?  I hesitate to just delete my tables and start over becaus= e this error will reoccur.  

    Best regards,
    Mark Brady
    From: Adrian Klaver <adr= ian.klaver@aklaver.com>
    Sent: Thursday, March 6, 2025 3:34 PM
    To: mark bradley <markbradyju@outlook.com>
    Cc: pgsql-general <pgsql-general@postgresql.org>
    Subject: Re: Duplicate Key Values
     
    On 3/6/25 12:06, mark bradley wrote:

    My mistake I forgot to Cc list on my previous post, which was:

    That would be an issue and also would mean it is not a PK.

    In psql  do:

    \d dataset

    and show the results as text in your reply.

    Ccing list


    The below shows there is an index("dataset_pkey") on node_id.

    Note, reindexing will take a lock on the table that prevents changing
    data while the operation is running. See the below for more information:
    https:= //www.postgresql.org/docs/current/sql-reindex.html

    If the table is not to big and you can interrupt access to it then the
    simplest command to run would be:

    REINDEX  TABLE dataset;

    > Universal Metadata Schema=3D# \d dataset
    >                    &= nbsp;              Table "public.da= taset"
    >            Column       &= nbsp;   |           Type      =      | Collation |
    > Nullable | Defau
    > lt
    > ---------------------------+---------------------------+-----------+--= --------+------
    > ---
    >   node_id               &= nbsp;   | integer               &nb= sp;   |           |
    > not null |
    >   dataset_name             &nb= sp;| character varying(25)     |         &nbs= p; |
    > not null |
    >   notes               &nb= sp;     | text               &= nbsp;      |           |  = ;
    >         |
    >   dataset_type             &nb= sp;| database_type             |    = ;       |
    > not null |
    >   dataset_maturity          | datab= ase_maturity_type    |           |
    > not null |
    >   disposition             &nbs= p; | disposition_type          |     &nb= sp;     |
    > not null |
    >   start_date              = ;  | date                 &nbs= p;    |           |  
    >         |
    >   end_date               =    | date                =      |           |   >         |
    >   most_recent_update        | date  = ;                    | &n= bsp;         |  
    >         |
    >   update_periodicity        | interval &= nbsp;                |    = ;       |  
    >         |
    >   system_of_record          | text =                      = ;|           |  
    >         |
    >   point_of_contact          | integ= er                   |   =         |
    > not null |
    >   dataset_url             &nbs= p; | text                   &n= bsp;  |           |  
    >         |
    >   classification_level      | classification_= level_type |           |
    > not null |
    >   physical_location         | text  = ;                    | &n= bsp;         |  
    >         |
    >   quality_control           | yes_n= o_type               |     &nb= sp;     |
    > not null |
    >   dataset_documentation_url | text       &nbs= p;              |       &= nbsp;   |
    > not null |
    >   description             &nbs= p; | text                   &n= bsp;  |           |  
    >         |
    >   node_type              =   | node_type                = |           |  
    >         |
    >   dummy               &nb= sp;     | integer              = ;     |           |  
    >         |
    > Indexes:
    >      "dataset_pkey" PRIMARY KEY, btree (node_= id)
    > Foreign-key constraints:
    >      "node_id" FOREIGN KEY (node_id) REFERENC= ES node(node_id) NOT VALID
    >      "poc" FOREIGN KEY (point_of_contact) REF= ERENCES poc(poc_id) NOT VALID
    > Referenced by:
    >      TABLE "dataset_table" CONSTRAINT "d= ataset" FOREIGN KEY (node_id)
    > REFERENCES datas
    > et(node_id) NOT VALID
    >      TABLE "dataset_subject" CONSTRAINT "= ;dataset_subject_node_id_fkey"
    > FOREIGN KEY (no
    > de_id) REFERENCES dataset(node_id)
    >      TABLE "system_dataset" CONSTRAINT "= system_dataset_node_id_fkey"
    > FOREIGN KEY (node
    > _id) REFERENCES dataset(node_id) NOT VALID
    > Inherits: node
    >
    >
    > Best regards,
    > Mark Brady
    > _amazon.com/author/markjbrady <https://amazon.com/author/markjbrady>_
    > ----------------------------------------------------------------------= --
    > *From:* Adrian Klaver <adrian.klaver@aklaver.com>
    > *Sent:* Thursday, March 6, 2025 3:03 PM
    > *To:* mark bradley <markbradyju@outlook.com>
    > *Subject:* Re: Duplicate Key Values
    > On 3/6/25 10:51, mark bradley wrote:
    > Reply to list alos.
    > Ccing list.
    >
    >> Looks like there is no index on node_id at the moment
    >
    > That would be an issue and also would mean it is not a PK.
    >
    > In psql  do:
    >
    > \d dataset
    >
    > and show the results as text in your reply.
    >
    >>
    >>
    >> Mark Brady, Ph.D.
    >> Deputy Chief Data Officer, TRMC
    >> _amazon.com/author/markjbrady <https://amazon.= com/author/markjbrady
    > <https://amazon.co= m/author/markjbrady>>_
    >> ------------------------------------------------------------------= ------
    >> *From:* Adrian Klaver <adrian.klaver@aklaver.com>
    >> *Sent:* Thursday, March 6, 2025 1:22 PM
    >> *To:* mark bradley <markbradyju@outlook.com>; Ron Johnson >> <ronljohnsonjr@gmail.com>; pgsql-general <pgsql-general@p= ostgresql.org>
    >> *Subject:* Re: Duplicate Key Values
    >> On 3/6/25 10:11, mark bradley wrote:
    >>> Here is the table definition:
    >>>
    >>>
    >>> And here is the error message I get when I try to delete a dup= licate:
    >>
    >> Please answer the following:
    >>
    >> 1) Did you not see duplicates with the old version of pgAdmin4? >>
    >> 2) What do you see if you use psql?
    >>
    >> 3) Did you upgrade/move the Postgres server or the underlying OS?<= br> >>
    >> 4) Have you tried reindexing the node_id field?
    >>
    >>>
    >>>
    >>> Mark Brady,
    >>> _amazon.com/author/markjbrady <https://ama= zon.com/author/markjbrady
    >> <https://amazon.com/author/markjbrady
    > <https://amazon.co= m/author/markjbrady>>>_
    >>> --------------------------------------------------------------= ----------
    >>
    >> --
    >> Adrian Klaver
    >> adrian.klaver@aklaver.com
    >>
    >
    > --
    > Adrian Klaver
    > adrian.klaver@aklaver.com
    >

    --
    Adrian Klaver
    adrian.klaver@aklaver.com

    --_000_SJ2PR22MB43286857EAC74D1EE332B08CBAD52SJ2PR22MB4328namp_--