Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 5EE342E009F for ; Mon, 9 Jun 2008 13:10:58 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 54986-06 for ; Mon, 9 Jun 2008 13:10:54 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from alexis.jtlnet.com (alexis.jtlnet.com [69.36.9.81]) by developer.postgresql.org (Postfix) with ESMTP id 74D632E00A1 for ; Mon, 9 Jun 2008 13:10:38 -0300 (ADT) Received: from [192.168.10.103] (cpe-075-177-177-228.nc.res.rr.com [::ffff:75.177.177.228]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by alexis.jtlnet.com with esmtp; Mon, 09 Jun 2008 12:09:14 -0400 id 000802D0.484D55AA.00007C55 Message-ID: <484D55FA.3050002@dunslane.net> Date: Mon, 09 Jun 2008 12:10:34 -0400 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.0.9-3.fc6 pango-text SeaMonkey/1.0.9 MIME-Version: 1.0 To: Simon Riggs CC: Tom Lane , "Decibel!" , Robert Treat , pgsql-hackers@postgresql.org Subject: Re: pg_dump restore time and Foreign Keys References: <1212647003.19964.19.camel@ebony.site> <4847D4A7.70309@dunslane.net> <1212670595.19964.55.camel@ebony.site> <200806071308.00845.xzilla@users.sourceforge.net> <1212860515.12046.78.camel@ebony.site> <484ADAD4.2080701@dunslane.net> <19362.1213023432@sss.pgh.pa.us> <1213024379.12046.111.camel@ebony.site> <484D4AE7.2050209@dunslane.net> <1213026379.12046.119.camel@ebony.site> In-Reply-To: <1213026379.12046.119.camel@ebony.site> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/404 X-Sequence-Number: 119517 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