Re: pg_dump restore time and Foreign Keys

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

In response to

Browse pgsql-hackers by date

  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