Re: pg_dump: Sorted output, referential integrity - Mailing list pgsql-hackers
From | Rod Taylor |
---|---|
Subject | Re: pg_dump: Sorted output, referential integrity |
Date | |
Msg-id | 002a01c182c6$9e8953a0$8001a8c0@jester Whole thread Raw |
In response to | Re: pg_dump: Sorted output, referential integrity (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
List | pgsql-hackers |
If you're going to allow bypassing data integrity checks (great for speed!) perhaps one should be introduced to quickly confirm the integrity of the file itself? A checksum on the first line will validate the contents through the rest of the file. It'll take a few minutes to confirm a multi-GB sized file but in comparison to load time it may be worthwhile to look into. That way you can ensure it's the same as it was when it was dumped and fsck or other accidental editing didn't remove the middle of it. Intentional modifications won't be stopped but backups should be treated the same as the database is security wise. -- Rod Taylor This message represents the official view of the voices in my head ----- Original Message ----- From: "Philip Warner" <pjw@rhyme.com.au> To: "Jan Wieck" <janwieck@yahoo.com>; "Stephan Szabo" <sszabo@megazone23.bigpanda.com> Cc: "Christof Petig" <christof@petig-baender.de>; "PostgreSQL Hackers" <pgsql-hackers@postgresql.org> Sent: Tuesday, December 11, 2001 10:03 PM Subject: Re: [HACKERS] pg_dump: Sorted output, referential integrity > At 10:34 11/12/01 -0500, Jan Wieck wrote: > > > > We don't want to define the constraints with ALTER TABLE > > because this means checking data on restore that doesn't need > > to be checked at all (in theory). If he has a crash of a > > critical system and restores from a dump, I bet the farm that > > he wants it FAST. > > This is just an argument for (a) using ALTER TABLE (since it will > also prevent PK indexes being created, and make it FASTer), and > (b) the ability to 'SET ALL CONSTRAINTS OFF' (or similar) to > prevent the ALTER TABLE from forcing validation of the constraint. > > The current situation of creating constraint triggers is IMO not > acceptable in the long term. > > There are also enough people who just restore one table to warrant > the ability for pg_dump to optionally run with constraints ON. > > > ---------------------------------------------------------------- > Philip Warner | __---_____ > Albatross Consulting Pty. Ltd. |----/ - \ > (A.B.N. 75 008 659 498) | /(@) ______---_ > Tel: (+61) 0500 83 82 81 | _________ \ > Fax: (+61) 0500 83 82 82 | ___________ | > Http://www.rhyme.com.au | / \| > | --________-- > PGP key available upon request, | / > and from pgp5.ai.mit.edu:11371 |/ > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
pgsql-hackers by date: