From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Decibel!" <decibel(at)decibel(dot)org>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_dump restore time and Foreign Keys |
Date: | 2008-06-09 16:10:34 |
Message-ID: | 484D55FA.3050002@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
>> But we don't know it for dead sure, we only think we do. What if the
>> data for one or other of the tables is corrupted? We'll end up with data
>> we believe is consistent but in fact is not, ISTM. If you can somehow
>> guarantee the integrity of data in both tables then we might be
>> justified in assuming that the FK constraint will be consistent - that's
>> why I suggested some sort of checksum mechanism might serve the purpose.
>>
>
> Agreed.
>
> Can we get COPY to output the checksum of its output as part of the
> command tag? How else can we return the checksum? In $file.cksum for any
> given output file?
>
It seems a reasonable idea to use the command tag, unless that's going
to break lots of stuff. I think the only thing we can usefully checksum
is the output lines in the client encoding.
> We can then use an explicit checksum option in the COPY when we reload,
> with CHECKSUM option.
>
>
We need rather more than this to make sure your facility isn't abused.
That's the part that I haven't been able to think of a good answer for
(yet).
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2008-06-09 16:17:40 | proposal: new contrib module - session variables |
Previous Message | Filip Rembiałkowski | 2008-06-09 16:09:24 | Re: pg_dump restore time and Foreign Keys |