On Mon, 2003-10-06 at 01:47, Shridhar Daithankar wrote:
> Ron Johnson wrote:
> >>All that we basically need for PITR is to provide management code that
> >>lets old WAL segments get archived off to tape (or wherever) rather than
> >>deleted, plus some kind of control that lets the roll-forward process be
> >>stopped at the desired point-in-time rather than necessarily running to
> >>the end of the available WAL data. This isn't a trivial amount of code,
> >>but there's no great conceptual difficulty either.
> >
> >
> > Hope everybody realizes that the amount of WALs will get very big
> > on active-update systems...
>
> Of course they will be recycled in some point of time or other. And even if
???? Of course they'll get recycled, after you dump them, prior
to the nightly pg_dump.
> postgresql would provide PITR abilities, that would be nearly useless if WAL is
> recycled.. Its a space/time tradeoff issue..
Again, ?????. Typically (i.e., on DBMSs that currently have PITR,
it's possible to do a "pg_dump" on Sunday, and *only* do "WAL dumps"
each subsequent night, and be able to restore the DB to the point
of failure by doing a "pg_restore" and then applying X number of
"WAL dumps" in sequence.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA
YODA: Code! Yes. A programmer's strength flows from code
maintainability. But beware of Perl. Terse syntax... more than
one way to do it...default variables. The dark side of code
maintainability are they. Easily they flow, quick to join you
when code you write. If once you start down the dark path,
forever will it dominate your destiny, consume you it will.