Content-Type: text/plain; charset="iso-8859-15"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From: "Daniel Verite" <daniel@manitou-mail.org>
Subject: Re: libc to libicu via pg_dump/pg_restore?
To: "Paul Foerster" <paul.foerster@gmail.com>
Cc: Adrian Klaver
 <adrian.klaver@aklaver.com>,
 Pgsql-General List <pgsql-general@lists.postgresql.org>
In-Reply-To: <D46171D1-80B9-4E81-BC26-D47319B90CE3@gmail.com>
Date: Fri, 07 Feb 2025 14:29:05 +0100
Message-Id: <669e44d4-01fd-4ae2-9918-4396a7f8f070@manitou-mail.org>
Archived-At: <https://www.postgresql.org/message-id/669e44d4-01fd-4ae2-9918-4396a7f8f070%40manitou-mail.org>
Precedence: bulk

	Paul Foerster wrote:

> >> pg_restore: error: could not execute query: ERROR:  insert or update o=
n table "table_1" violates foreign key constraint "..._fk"
> >> DETAIL:  Key (dokument_id)=3D(1000033680) is not present in table "...=
".
> >=20
> > Is dokument_id an integer field?
>=20
> 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,
--=20
Daniel V=E9rit=E9=20
https://postgresql.verite.pro/