I didn't used pg_dump/restore until today and finally found my mistake which lead to the "problem" described below.
The output "depends on" comes from the -l (l as Lima) flag, what i wanted was the -1 (number one) flag, which stands for single transaction in pg_restore. As -l does not execute anything, nothing was logged in the postgres server log and none error was shown anywhere.
Both chars looked so identical in my editors/shells that i thought i used -1, in fact using -l.
It's always the tiny obvious thing, which we do not see.
Best regards,
Chris
Am 28. März 2024 16:57:04 schrieb Fire Emerald <fire.github@xxxxxxxxx>:
Am 28. März 2024 15:00:06 schrieb Tom Lane <tgl@xxxxxxxxxxxxx>:Fire Emerald <fire.github@xxxxxxxxx> writes:Then i did a pg_restore -d target --verbose -Fc file.dump and saw in theoutput this:5145 0 730750 TABLE subpartitions backends_y2024w03 userA; depends on: 237.... and so on ...That is not an error, it's just verbose display of one of the itemsin the dump.Well, I know it's not an error, but it's everything i got. There was no error shown. The command completed, but without anything imported.Nothing was restored.You would need to show us the actual errors. (Suggestion:leave off --verbose, it's just clutter.) A guess though isthat the import failed because of foreign key constraints.--data-only mode is not good at ordering the table loads toensure that FK constraints are satisfied on-the-fly.regards, tom laneAs i said, the same import but with INSERT INTOs worked without any issues. So no, there are no FK constraints failing.But the target and source table had partitioned tables attached, using ATTACH PARTITION.The schema was like:db1 schema1 public table1 (links to the listed below)db1 schema1 subpartitions backends_y2024w03db1 schema1 subpartitions backends_y2024w04db1 schema1 subpartitions backends_y2024w05The partitioning must be the problem somehow.
