ow wrote:
>--- Andreas Pflug <pgadmin@pse-consulting.de> wrote:
>
>
>>Yes, I mentioned it just a few days when discussing dependency in pg_dump.
>>This is somewhat complementary to WAL and PITR. I'm seeking for a fast
>>way to dump and restore a complete database, like physical file copy,
>>without shutting down the backend. I was thinking of a BACKUP command
>>that streams out the files including any indexes and non-vacuumed
>>tuples. A database recreated from that wouldn't be as clean as a
>>pg_dump/pg_restored database, but it would be up much faster, and there
>>wouldn't be any dependency problem.
>>This doesn't really replace pg_dump/pg_restore, because it probably
>>wouldn't be able to upgrade a cluster. Still, it would be helpful for
>>disaster recovery.
>>
>>
>>
>
>I think creating a FK without verification check is still needed, especially in
>case if:
>1) original db is corrupted
>2) during cluster upgrade
>
>
Agreed. This might be useful for replication purposes too; in MSSQL, you
can write "CREATE TRIGGER ... NOT FOR REPLICATION". I'd like to see a
transaction safe way (ENABLE/DISABLE TRIGGER command) for this.
>3) there's a need to BACKUP/RESTORE a *schema* instead of db.
>
>Thanks
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Free Pop-Up Blocker - Get it now
>http://companion.yahoo.com/
>
>---------------------------(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
>
>
>
