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 1tFUiE-00DJPX-Il for pgsql-general@arkaria.postgresql.org; Mon, 25 Nov 2024 08:44:54 +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 1tFUiD-00DStM-4s for pgsql-general@arkaria.postgresql.org; Mon, 25 Nov 2024 08:44:53 +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 1tFUiC-00DStE-Pk for pgsql-general@lists.postgresql.org; Mon, 25 Nov 2024 08:44:52 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tFUiA-003k0W-Pk for pgsql-general@postgresql.org; Mon, 25 Nov 2024 08:44:52 +0000 Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5cfcb7183deso8825109a12.0 for ; Mon, 25 Nov 2024 00:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732524289; x=1733129089; darn=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=5gc4lVjqsa9ymWmKeVVSq/DpFm2HdSDiogHsGsfS2jM=; b=QZIHQzFHyOzrl3Dz7mlIe9T0wFHA7TEO5jqnO31zQGsTp3D1tgkqmUqx0jWLrxBkVs yb611G3n3vJkNpNIEUJb560A9YJ5nkZpbRV+A+es61vGjJ53T0W1sc4WML9YJixSGiGv kB9dioN8pJhnNtBGqU7rpcEn+1Hh2Mh0Lm7Gmgm5/sWuST/VcEJM+6XeFXPt6dlKcqqL iI/iy3LAXqa6fNRsORigf0CgUntLSSZ7ZrMFBDhQEubxdd9rZH8YWkKpY/w9S19SPAh9 s4TN0bQZT/TVPJFviMn8ej4GGI8p4P2NZmiQTYcWdoG3fcSded7ICrGti4eUMDGvkAWj LoHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732524289; x=1733129089; 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=5gc4lVjqsa9ymWmKeVVSq/DpFm2HdSDiogHsGsfS2jM=; b=pk10Lp/8pQhI7zg6X9NxP488rrdYz3W9Afzxd+cJfeqEKJyzdADj/fu3/esf+9IPRk qGDts4uXOJZbuGlMmezvVBF6xFLJURSgW7/LJeBCOPeaaprY3+RDJV54k3bLbgxm4YUw Y7dhtZe1w+x8n4t4STqA72BpmV0D96F8uM80j3dnyJ1wX+94+5R8xAFWGxMakkbY7ZE4 9NGm8UPAntKNDsMX8EeIA7eDsGUGJf6A2QctoNNV82KAqZh7k97m4sePF8KS4sxh71Qd 3h1E2P/O1bzfEFOiu+gXmkDmY0i1Ahy0/Z2UdAM4a4igGoeJu0IuXSBY3C6RMlNkwcHn 4POg== X-Gm-Message-State: AOJu0Yy1ehT+iI7tHT4V8GaSCptnzc00UdXhRxiVapaNLEqnFNb2SdAp BTWrDlGnOOp2Fbxt3wSviTev3YrFA4JTs2Em+F/N+ma3+u62o6F4QZacJ/0+zRKD9y0go8woHlQ OxcadZ6O3A4xmkuTYyyMRYVA3wyY= X-Gm-Gg: ASbGnctqo0hde9xtEwmi7+uFKPYjWuNXUTE1aHZzSQw40CKLVpdNeByH8dwN3QyBhB1 Ed3I2kRyOz6rmnZPhRCKWZsVQNWvvuS2u X-Google-Smtp-Source: AGHT+IGhGNS8hhzZMWy5MyDUso95xK9aumyqqqDBVzkkFJOpsjyk0OUyYgrLnXjEUPAPiA5HrYyU5wBpn2Q0ZpIpdkI= X-Received: by 2002:a17:907:7853:b0:a9a:17be:fac7 with SMTP id a640c23a62f3a-aa509a07836mr1362546866b.14.1732524289368; Mon, 25 Nov 2024 00:44:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shashidhar Reddy Date: Mon, 25 Nov 2024 14:14:37 +0530 Message-ID: Subject: Re: Unique key constraint Issue To: ajit wangkhem Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000d531800627b8beb7" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d531800627b8beb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ajit, Thank you for your reply! The result of the query is same across all servers and yes streaming replication does not have any issue but the question is how did duplicate values entered when there unique key in place. On Mon, 25 Nov, 2024, 1:21=E2=80=AFpm ajit wangkhem, wrote: > Output should be consistent across servers below query o/p > > SELECT conname, pg_get_constraintdef(oid) > FROM pg_constraint > WHERE conrelid =3D 'your table name'::regclass AND contype =3D 'u'; > (different datatype combine in UK is not an issue). This issue may not > happen in asynchronous, log shipping or streaming replication. In logical > replication it may create problem. > > On Mon, Nov 25, 2024 at 12:01=E2=80=AFPM shashidhar Reddy < > shashidharreddy001@gmail.com> wrote: > >> Hello, >> >> We have postgresql servers with PostgreSQL 13.10 on Ubuntu release >> 22.04. >> >> The issue is a unique key constraint with two columns one is character >> another is integer. At some point the unique key did not work as I see >> duplicate values with these two columns combination and it happened on >> multiple servers on multiple databases on same table with same unique ke= y. >> I tried db dump and restore but the key is failing to create when restor= e >> with duplicate value errors. >> >> >> >> --000000000000d531800627b8beb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ajit,

Tha= nk you=C2=A0for your reply!

The result of the query is same across all servers and yes streaming re= plication does not have any issue but the question is how did duplicate val= ues entered when there unique key in place.

On Mon, 25 Nov, 2024, 1:21= =E2=80=AFpm ajit wangkhem, <a= jit.wangkhem@gmail.com> wrote:
=C2=A0 Output=C2=A0should be consistent across servers = below query o/p

SELECT conname, pg_get_constraintdef(oid= )
FROM pg_constraint
WHERE conrelid =3D 'your table name'::re= gclass AND contype =3D 'u';
(different datatype=C2=A0comb= ine=C2=A0in UK is not an issue). This issue may not happen in asynchronous,= log shipping or streaming replication. In logical replication it may creat= e problem.

On Mon, Nov 25, 2024 at 12:01=E2=80=AFPM shashidhar Reddy &= lt;shashidharreddy001@gmail.com> wrote:
Hello,

We have postgre= sql servers with PostgreSQL 13.10=C2=A0 =C2=A0on Ubuntu release 22.04.

The issue is a unique key co= nstraint with two columns one is character another is integer. At some=C2= =A0point the unique key did=C2=A0not work as I see duplicate values with th= ese two columns combination and it happened on multiple servers on multiple= databases on same table with same unique key. I tried db dump and restore = but the key is failing to create when restore with duplicate value errors.<= /div>



--000000000000d531800627b8beb7--