From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Марат Гасанян <marat_gasanyan(at)mail(dot)ru>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Problem with constraint unique. |
Date: | 2024-12-12 06:47:24 |
Message-ID: | 0c1f6b24a56b4ee79331c656efce9ca622ffa0a1.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, 2024-12-11 at 17:47 +0300, Марат Гасанян wrote:
> I apologies for bothering your team, before send this message we google the
> problem and was not able to find any tips about it. Our project encounter
> with quite strange situation where we found violation of unique constraint
> of primary key. We have a table that has an attribute ID as PK. The table
> name enerstorymain_task_info. Surprisingly the query
> select id, count(*) from enerstroymain_task_info group by 1 having count(*) > 1
> return a lot of rows. Than we rechecked PK it is ok. So we supposed that
> some how we had dropped the PK and then created duplicates and than rebuild
> the PK, but in this case PK would not rebuild. To avoid any weird settings
> I run the query from PGAdmin and DBView from different computers.
> Also I doubt that any kind problem like repeatable red could be the reason
> due to insert operation is done only a server without any complicated query.
> I mean simple INSERT INTO ….
No, dropping and re-creating the constraint cannot be the explanation,
unless the primary key constraint is NOT VALID.
With "uuid", it also cannot be a collation problem.
The best thing to get rid of this data corruption is to delete the extra
entries and then to sump and restore the data to a new database.
Check if your hardware has problems.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2024-12-12 12:39:40 | Re: "memory exhausted" in query parser/simplifier for many nested parentheses |
Previous Message | Laurenz Albe | 2024-12-12 06:40:31 | Re: TimestampTz->Text->TimestampTz casting fails with DateStyle 'Postgres' |