Re: Proposal: More flexible backup/restore via pg_dump

> I must admit that I've been working on the assumption that people using
> PostgreSQL don't have multi-GB (compressed) database dumps, so that (in
> theory) a restore can be loaded onto disk from tape before being
> used.

Are you are also assuming that a backup fits in a single file,
i.e. that anyone with >2GB of backup has some sort of large file
support?

> Sanity Check: does fseek work on tapes? If not, what is the correct way to
> read a particular block/byte from a file on a tape?

As someone else answered: no. You can't portably assume random access
to tape blocks.

> The output scheme will be encapsulated, and in the initial version will be
> a custom format (since I can't see an API for tar files)

You can use a standard format without there being a standard API.

Using either tar or cpio format as defined for POSIX would allow a lot
of us to understand your on-tape format with a very low burden on you
for documentation. (If you do go this route you might want to think
about cpio format; it is less restrictive about filename length than
tar.)

There is also plenty of code lying around for reading and writing tar
and cpio formats that you could steal^H^H^H^H^H reuse. The BSD pax
code should have a suitable license.

> pg_restore will use the same custom IO routines to allow IO to
> tar/directory/custom files. In the first pass, I will do custom file
> IO.

Presumably you'd expect this file I/O to be through some standard API
that other backends would also use? I'd be interested to see this;
I've got code for an experimental libtar somewhere around here, so I
could offer comments at least.

> BUT AFAIK, fseek does not work on STDOUT, and at the current time pg_backup
> will use fseek.

It depends what fseek is whether it works on standard output or not.
If it's a pipe, no. If it's a file, yes. If it's a tape, no. If
it's a ...

Not using fseek() would be a win if you can see a way to do it.

Regards,

Giles