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:

Previous
From: Doug McNaught
Date:
Subject: Re: Explicit configuration file
Next
From: "Marc G. Fournier"
Date:
Subject: Re: Beta4 ...