Jesper Krogh <jesper@krogh.cc> writes: > The tables are running a "home-made" timetravelling feature where a > contraint on the table implements the foreing keys on the table. You mean you have check constraints that do selects on other tables? You have just found out (one reason) why that's a bad idea. > How can I instruct pg_dumpall to turn off these constriants during > dump/restore? Drop the constraints in the source database. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

Jesper Krogh <jesper@krogh.cc> writes: > Tom Lane wrote: >> Drop the constraints in the source database. > That would be my workaround for the problem. But isn't it somehow > desirable that pg_dumpall | psql "allways" would work? Well, sure. The reason why this sort of thing is deprecated is exactly that the database can't promise it will work all the time. The DB has no way to know that your constraints do something they're not supposed to, and in particular no way to infer that there's a specific data loading order needed to keep the constraint from failing. We do allow you to do it, but if it breaks you get to keep both pieces. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match