| From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
|---|---|
| To: | jesusthefrog <jesusthefrog(at)gmail(dot)com> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: gen_random_uuid key collision |
| Date: | 2021-09-03 01:41:27 |
| Message-ID: | 51C76F82-C22A-46CC-BB14-17487A954D2B@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> On Sep 2, 2021, at 4:25 PM, jesusthefrog <jesusthefrog(at)gmail(dot)com> wrote:
>
> Anyone have any thoughts on this?
I agree with Peter's suggestion upthread to run amcheck on the index, but if that comes back with no corruption, can you verify that there are no rules or triggers that might cause multiple copies of the rows to be inserted? Likewise, can you verify that you have no replication subscriptions that could be putting duplicates into the table?
Another idea that seems unlikely given your lack of trouble with other tables is that you might check whether you have any functions that reset the seed for your random generator. I haven't looked specifically at your uuid generator, and I don't know if it gets nondeterministic randomness from /dev/random or similar, but deterministic random generators can be made to produce the same sequence again if the seed it reset.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | M Tarkeshwar Rao | 2021-09-03 06:50:35 | is there any memory leak with postgres version(12.x) - https://stackoverflow.com/questions/3849543/force-postgresql-to-release-allocated-memory |
| Previous Message | Peter Geoghegan | 2021-09-03 01:13:38 | Re: gen_random_uuid key collision |