Re: Upgrade time, dump+restore trouble.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tom Lane wrote:
> Jesper Krogh <jesper@xxxxxxxx> 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?

Yes. We do.. we have to .. in order to perserve the foreing-keys.
What we have in short is:
Added two timestamps on each columns, starttime,endtime. When endtime is
"null" the record is "current" and a view exposes this from the table.
The foreing keys are then implemented using contraints that look up the
id in the foreing table and ensures that there is a record where the
endtime is null present

> You have just found out (one reason) why that's a bad idea.

Do you have any other reasons?

>> How can I instruct pg_dumpall to turn off these constriants during
>> dump/restore?
> 
> 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?

Jesper
-- 
Jesper Krogh, jesper@xxxxxxxx


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux