Skip site navigation (1) Skip section navigation (2)

Re: Proposal: More flexible backup/restore via pg_dump

From: Giles Lean <giles(at)nemeton(dot)com(dot)au>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: More flexible backup/restore via pg_dump
Date: 2000-06-27 13:40:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Do we have any tape experts out there?

Don't even try.  The guaranteed portable subset of tape drive,
interface, device driver, and OS semantics is pretty limited.

I'm confident to stream one (tape) file of less than one tape capacity
to a drive and read it back sequentially.  These days you can probably
expect reliable end of media handling as well, but don't be too sure
what value errno will have when you do hit the end of a tape.

As soon as you start looking to deal with more advanced facilities you
will discover portability problems:

- autochanger interface differences
- head positioning on tapes with multiple files  (SysV v. BSD, anyone?)
- random access (yup, supported on some drives  ... probably all obsolete)
- "fast search marks" and similar

Some of these things can vary on the one OS if a tape drive is
connected to different interfaces, since different drivers may be

BTW I'm not a tape expert.  The problems in practice may be greater or
lesser than I've suggested.

I would be trying really hard to work out a backup format that allows
a one pass restore.  Rummaging around in the database when making the
backup and using some scratch space at that time isn't too bad.  Using
scratch space upon restore is more problematic; restore problems are
traditionally found at the worst possible moment!



pgsql-hackers by date

Next:From: Thomas LockhartDate: 2000-06-27 13:45:29
Subject: Re: SQL99 functions
Previous:From: Philip WarnerDate: 2000-06-27 13:39:41
Subject: Mailing List Archive Problem?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group