Hey - you *could* consider logging your commands elsewhere and use *that*
for incrementals. It wouldn't have all the nice features of transactions
so it might take some manual effor to recover but you may not need
anything beyond a naive implementation.
So alter your application to save all SQL that can modify the database and
use that to augment your normal scheduled backups.
Joshua b. Jore ; http://www.greentechnologist.org
On Sun, 7 Jul 2002, Martijn van Oosterhout wrote:
> On Sat, Jul 06, 2002 at 11:03:12PM -0400, Lamar Owen wrote:
> > On Saturday 06 July 2002 10:59 pm, Doug Fields wrote:
> > > If you want to "incrementalize" it, you could always keep a base, and diff
> > > the new dump against it, and store just the diff.
> >
> > > Be sure to run the output through bzip2 (or gzip -9) to save space.
> >
> > This doesn't work as well in practice as it would seem. Due to funkiness, the
> > output of pg_dump isn't (or wasn't the last time I tried diffing dumps)
> > necessarily always in the same order.
>
> Not just that, diff wants to be able to read the whole file in. Last I tried
> to diff two 500MB files on a 256MB machine it was not pretty.
>
> --
> Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> > There are 10 kinds of people in the world, those that can do binary
> > arithmetic and those that can't.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
>
>