| From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
|---|---|
| To: | "Paul Foerster" <paul(dot)foerster(at)gmail(dot)com> |
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Pgsql-General List <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: libc to libicu via pg_dump/pg_restore? |
| Date: | 2025-02-07 13:29:05 |
| Message-ID: | 669e44d4-01fd-4ae2-9918-4396a7f8f070@manitou-mail.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Paul Foerster wrote:
> >> pg_restore: error: could not execute query: ERROR: insert or update on table "table_1" violates foreign key constraint "..._fk"
> >> DETAIL: Key (dokument_id)=(1000033680) is not present in table "...".
> >
> > Is dokument_id an integer field?
>
> Yes, it's a bigint.
It's hard to imagine that the change of collation is related to the
failure to create that constraint.
When a value is present in the target table but the FK check does not
find it, often the cause is index corruption.
But if you've just imported that dump, the index on the target column
should be brand new.
Still, you may check it with pg_amcheck [1] or try rebuilding it
just in case.
[1] https://www.postgresql.org/docs/current/app-pgamcheck.html
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Sabino Mullane | 2025-02-07 14:53:10 | Re: libc to libicu via pg_dump/pg_restore? |
| Previous Message | ravi k | 2025-02-07 13:00:10 | Re: Commit Latency |